SUITABILITY  OF  UNIDATA  METAPPS  FOR 
INCORPORATION  IN  PLATFORM-INDEPENDENT 
USER-CUSTOMIZED  AVIATION  WEATHER 
PRODUCTS  GENERATION  SOFTWARE 

THESIS 

Harmen  P.  Visser,  Captain,  USAF 
AFIT/GM/ENP/02M-09 


DEPARTMENT  OF  THE  AIR  FORCE 
AIR  UNIVERSITY 

AIR  FORCE  INSTITUTE  OF  TECHNOLOGY 


Wright-Patterson  Air  Force  Base,  Ohio 


APPROVED  FOR  PUBEIC  REEEASE;  DISTRIBUTION  UNEIMITED 


Report  Documentation  Page 

Report  Date  Report  Type 

8  Mar  02  Final 

Dates  Covered  (from...  to) 

Jun  2001  -  Mar  2002 

Title  and  Subtitle 

Contract  Number 

Suitability  ot  Unidata  Metapps  tor  Incorporation  in 
Platform-Independent  User-Customized  Aviation 

Grant  Number 

Weather  Products  Generation  Software 

Program  Element  Number 

Author(s) 

Project  Number 

Capt  Harmen  P.  Visser,  USAF 

Task  Number 

Work  Unit  Number 

Performing  Organization  Name(s)  and 

Address(es) 

Air  Force  Institute  of  Technology  Graduate  School 
of  Engineering  and  Management  (AFIT/EN)  2950  P 
Street,  Bldg  640  WPAFB  OH  45433-7765 

Performing  Organization  Report  Number 

AEIT/GM/ENP/02M-09 

Sponsoring/Monitoring  Agency  Name(s)  and 
Address(es) 

Sponsor/Monitor’s  Acronym(s) 

AFWA/DNXT  ATTN;  Mr.  Bruce  Telfeyan  106 
Peacekeeper  Drive  Offutt  AFB  NE  68113-4039 

Sponsor/Monitor’s  Report  Number(s) 

Distribution/Availability  Statement 

Approved  for  public  release,  distribution  unlimited 

Supplementary  Notes 


Abstract 

Due  to  multiple  factors,  including  an  increase  in  military  operations  tempo  and  the  improved  resolution  of 
meteorological  models,  demand  for  access  to  customized  aviation  weather  products  has  increased 
exponentially.  This  has  given  rise  to  a  need  for  a  multi-purpose  interactive  aviation  weather  product 
generation  software  solution.  This  software  solution  must  be  platform-independent,  multiple  data  source 
access  configurable,  robust,  extensible  or  upgradeable,  user-friendly,  and  an  improvement  over  current 
visualization  applications  used  in  the  operational  military  aviation  weather  community.  This  thesis 
determines  whether  Unidata  MetApps  meets  these  criteria.  A  software  reuse  and  component-based 
engineering  approach  was  taken  in  this  thesis.  Two  experimental  applications  were  constructed  using  a 
software  design  approach  resembling  the  Facade  software  design  pattern.  The  first  application  used 
existing  MetApps  stand-alone  prototype  applications,  while  the  second  exploited  capabilities  of  the 
MetApps  component  library.  Both  experimental  applications  were  measured  against  the  above  set  of 
criteria  to  determine  their  suitability  for  incorporation  in  platform-independent  user-customized  aviation 
weather  products  generation  software.  The  results  prove  that  a  Facade  software  design  approach  can  be 
effectively  used  to  build  applications.  It  was  determined  however  that,  even  though  MetApps  shows 
promise,  it  may  not  be  suitable  for  incorporation  into  an  operational  application. 
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Abstract 

Due  to  multiple  factors,  including  an  increase  in  military  operations  tempo  and 
the  improved  resolution  of  meteorologieal  models,  demand  for  access  to  customized 
aviation  weather  produets  has  inereased  exponentially.  This  has  given  rise  to  a  need  for  a 
multi-purpose  interactive  aviation  weather  product  generation  software  solution.  This 
software  solution  must  be  platform-independent,  eonfigurable  for  multiple  data  souree 
aceess,  robust,  extensible  or  upgradeable,  user-friendly,  and  an  improvement  over  current 
visualization  applications  used  in  the  operational  military  aviation  weather  community. 
The  purpose  of  this  thesis  is  to  determine  whether  Unidata  MetApps  meets  these  criteria. 

A  software  reuse  and  eomponent-based  engineering  approaeh  was  taken  in  this 
thesis.  Two  experimental  applications  were  constructed  using  a  software  design 
approach  resembling  the  Facade  software  design  pattern.  The  first  application  used 
existing  Unidata  MetApps  stand-alone  prototype  applications,  while  the  seeond  exploited 
eapabilities  of  the  MetApps  component  library.  Both  experimental  applications  were 
measured  against  the  above  set  of  eriteria  to  determine  their  suitability  for  incorporation 
in  platform-independent  user-eustomized  aviation  weather  products  generation  software. 
The  results  prove  that  a  Facade  software  design  approach  can  be  effectively  used  to  build 
meteorological  applications.  It  was  determined  however  that,  even  though  MetApps 
shows  promise,  it  may  not  be  suitable  for  incorporation  into  an  operational 
meteorological  software  solution. 
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SUITABILITY  OF  UNIDATA  METAPPS  FOR  INCORPORATION  IN  PLATFORM- 


INDEPENDENT  USER-CUSTOMIZED  AVIATION  WEATHER  PRODUCTS 

GENERATION  SOFTWARE 


I.  Introduction 


LI  Background 

In  1995,  the  Air  Force  Weather  Information  Network  (AFWIN)  came  online. 
Under  the  direction  of  the  Air  Force  Global  Weather  Central  Product  Improvement 
Branch  (the  precursor  of  today's  Air  Force  Weather  Agency  Technology  Exploitation 
Branch)  AFWIN  provided  access  to  Relocatable  Window  Model  (RWM)  products 
produced  by  automated  Mesoscale  Gridded  Window  Display  System  (MGWDS) 
sessions.  The  RWM  was  superseded  in  1998  by  the  National  Center  for  Atmospheric 
Research/Pennsylvania  State  University  Mesoscale  Model  5  (MM5),  which  is  still 
running  today.  MM5  products  were  thenceforth  produced  directly  for  distribution  to 
customers  via  AFWIN.  The  Air  Force  Weather  Agency  Technology  Exploitation  Branch 
produced  displays  for  hundreds  of  standard  and  derived  meteorological  parameters  for 
weather  forecaster  use  worldwide.  By  1999,  as  the  MM5  began  to  include  more  theaters, 
the  number  of  pre-staged  automated  weather  products  had  expanded  to  over  350,000  per 
day  (Telfeyan,  2001).  This  consisted  of  a  huge  archive  of  Graphics  Interchange  Format 
(GIF)  images,  which  were  completely  recycled  every  24  hours.  A  large  percentage  of  the 
350,000  images  were  never  viewed  by  anyone.  Producing  350,000  archived  images  per 
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day  was  an  inefficient  use  of  computing  resources  and  it  became  imperative  that  the  large 
number  of  pre-staged  automated  weather  products  be  reduced. 

The  concept  was  introduced  of  providing  interactive  interfaces  on  AFWIN  that 
would  allow  an  Internet  user  to  specify  what  they  needed  and  have  the  Air  Force  Weather 
Agency  computing  resources  produce  the  required  charts  upon  demand.  An  interface 
was  developed  called  Interactive  Meteorogram  and  Skew  T  (IMaST).  A  meteorogram  is 
a  chart  in  which  one  or  more  meteorological  variables  are  plotted  against  time  while  a 
skew  T  (an  abbreviation  of  skew  T  -  log  p)  is  a  standard  plot  used  by  meteorologists  to 
analyze  data  from  a  sounding.  IMaST  allowed  a  user  to  produce  a  meteorogram  or  skew 
T  diagram  for  any  location  within  the  geographical  domains  of  various  meteorological 
forecast  models  including  the  MM5.  The  user  was  prompted  to  enter  either  latitude  and 
longitude  coordinates,  an  ICAO  (International  Civil  Aviation  Organization)  four-letter 
identifier,  or  point  and  click  a  location  on  a  number  of  theater  maps  using  a  mouse. 

Air  Force  weather  went  through  reorganization  in  the  late  1990’s.  As  part  of  this 
reorganization,  the  production  of  many  theater-specific  aviation  weather  products  was 
decentralized  and  transferred  to  the  newly  created  Air  Force  regional  weather  hubs 
(Sembach,  Shaw,  etc.).  However,  responsibility  for  the  generation  of  user-customized 
meteorological  products  using  meteorological  model  data  was  left  with  the  Air  Force 
Weather  Agency  Technology  Exploitation  Branch.  The  reason  for  this  was  the 
requirement  for  large  computing  resources  to  generate  the  required  meteorological 
forecast  model  data  files  and  the  configuration  complexities  involved  in  running  the 
necessary  Grid  Analysis  and  Display  System  (GrADS)  software  with  an  associated 
JavaScript  interface.  Thus  there  remained  the  problem  of  a  single  point  of  failure.  The 
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regional  Air  Force  weather  hubs  have  a  wide  variety  of  different  computing  hardware  at 
their  disposal,  consisting  mostly  of  Microsoft  Windows  based  personal  computers  (PC’s) 
and  some  UNIX  workstations.  Compared  to  the  Air  Force  Weather  Agency  Technology 
Exploitation  Branch,  the  weather  hubs’  computing  resources  are  more  limited. 

In  2001,  the  Interactive  Gridded  Analysis  and  Display  System  (IGrADS)  was 
developed  to  eventually  replace  IMaST.  IGrADS  expanded  the  capabilities  of  IMaST  to 
include  vertical  cross-sections,  alphanumeric  model  output,  two-dimensional  weather 
charts  with  user-selected  parameters,  severe  weather  meteorograms,  etc.  IGrADS 
replaced  the  IMaST  JavaScript  interface  with  one  based  on  Java™  classes.  This  IGrADS 
feature  takes  advantage  of  the  built-in  capabilities  of  modern  Java^^’^-enabled  Internet 
content  browsers  such  as  Netscape  and  Internet  Explorer  5.0  to  run  Java™  applications 
over  the  Internet.  Nonetheless,  GrADS  was  still  the  behind-the-scenes  engine  that 
produced  all  the  user-requested  meteorological  products  distributed  via  IGrADS. 

The  Air  Eorce  Weather  Agency  Technology  Exploitation  Branch  currently 
depends  on  IGrADS  to  provide  user-customized  meteorological  products  to  its  customers 
through  its  Joint  Air  Eorce  and  Army  Weather  Information  Network  (JAAWIN)  Internet 
site.  Due  to  multiple  factors,  including  an  increase  in  operations  tempo  and  the  improved 
resolution  of  meteorological  models,  the  demand  for  access  to  customized  aviation 
weather  products  has  increased  exponentially  over  the  last  few  years.  This,  combined 
with  the  need  for  increased  network  security  precautions  to  prevent  unauthorized  access 
to  US  Air  Eorce  weather  data,  has  slowed  the  delivery  of  products.  In  its  current 
configuration,  JAAWIN  provides  its  user-customized  aviation  weather  products  from  a 
single  Internet  web  site  that  has  become  a  sort  of  "bottleneck"  and  a  single  point  of 
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failure  in  the  delivery  system  for  this  speeifie  type  of  meteorologieal  product.  Up  to  this 
point,  GrADS  had  served  the  Air  Force  meteorological  community  well  in  its  role  as  the 
JAAWIN  product  generator  for  user-customized  aviation  weather  products.  The  demise 
of  GrADS  use  at  the  Air  Force  Weather  Agency  Technology  Exploitation  Branch  is  in 
sight  however.  The  Air  Force  is  restricted  in  what  it  can  do  to  the  GrADS  software  due 
to  license  issues.  The  Technology  Exploitation  Branch  eventually  wants  to  greatly 
reduce  its  dependence  on  GrADS  and  commercial-off-the-shelf  (COTS)  software 
applications  (Telfeyan,  2001).  As  IGrADS  was  being  readied  to  go  operational  on  the 
Joint  Air  Eorce  and  Army  Weather  Information  Network  (or  JAAWIN),  the  search  had 
already  begun  for  a  stand-alone  platform-independent  solution  that  would  eventually 
eliminate  the  Air  Eorce's  dependence  on  COTS  software  and  GrADS. 

In  a  1997  proposal  to  the  National  Science  Eoundation,  after  12  years  of 
successfully  supporting  universities  in  the  exploitation  of  information  technologies  in 
atmospheric  research,  the  University  Corporation  for  Atmospheric  Research  (UCAR) 
Unidata  Program  Center  proposed  a  shift  in  its  software  emphasis  to  the  Java^"^ 
programming  language.  UCAR  stated  that  the  reason  for  the  change  of  emphasis  was  to 
enable  the  Unidata  academic  research  community  to  fully  exploit  the  power  of 
networking  and  distributed  computing  available  through  Java™.  This  shift  in  emphasis 
did  not  merely  represent  a  change  in  programming  language  but  rather  a  shift  towards  a 
new  model  of  architecture-neutral,  object-oriented,  distributed,  secure,  multithreaded,  and 
reusable  software.  Unidata  emphasized  that  the  advances  achieved  by  Java™  were  "... 
so  important  that  the  greatest  risk  would  be  not  to  pursue  them. . ."  (UCAR,  1997)  Born 
out  of  the  proposal  was  a  suite  of  applications  known  as  MetApps  (Meteorological 
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Applications).  Over  the  past  four  years  the  UCAR  Unidata  Program  Center  has 
eoordinated  the  further  development  of  MetApps.  MetApps  is  now  a  platform- 
independent  meteorologieal  software  suite  consisting  of  a  set  of  object-oriented  Java™ 
classes  and  abstract  data  types  (Caron,  1999).  The  question  at  hand  is  whether  the 
Unidata  MetApps  elasses  and  prototype  applications  are  suitable  for  incorporation  in  an 
operational  platform-independent  interactive  aviation  weather  produets  generation 
software  package. 

1 .2  Statement  of  the  Problem 

There  has  arisen  within  the  military  meteorological  community  a  need  for  multi¬ 
purpose  interactive  aviation  weather  products  generation  software  solution.  This 
software  solution  must  satisfy  six  main  requirements.  First,  the  solution  in  question 
should  be  platform-independent.  Due  to  the  unpredictable  nature  of  worldwide  military 
operations,  identical  software  platforms  at  diverse  geographieally  separated  loeations 
cannot  and  should  not  be  expected.  Second,  the  software  solution  must  not  be  restricted 
to  obtaining  data  from  a  single  source,  as  has  been  the  case  in  the  past.  A  single  data 
source  for  meteorological  data  creates  an  opportunity  for  one’s  adversaries  to  undermine 
the  capability  of  commanders  to  obtain  the  most  current  aviation  weather  information. 
Third,  the  solution  must  be  robust.  “Normal”-sized  model  data  files  should  be  able  to  be 
run  on  a  eomponent-based  application  without  putting  undue  strain  on  a  mid-level 
Windows  PC  or  an  average  UNIX  workstation.  Fourth,  the  solution  must  be  extensible 
or  upgradeable.  An  application  built  using  reusable  components  should  be  relatively  easy 
to  adapt  to  changes  in  its  components  (this  requirement  is  somewhat  subjective).  Fifth, 
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the  software  solution  should  be  user-friendly.  Although  this  requirement/eriteria  is 
somewhat  subjeetive,  it  must  be  kept  in  mind  that  users  naturally  will  avoid  software  that 
is  difficult  to  use.  Sixth,  the  selected  software  solution  must  be  an  improvement  over 
current  visualization  applications  used  in  the  operational  aviation  weather  environment. 

1.3  Scope 

The  Air  Force  Weather  Agency  Technology  Exploitation  Branch  would  like  to 
know  if  Uni  data  Meteorological  Applications  (MetApps)  stand-alone  prototype 
applications  or  libraries  are  suitable  for  incorporation  into  next-generation  platform 
independent  interactive  user-customized  aviation  weather  products  generation  software. 
This  project  focuses  specifically  on  the  suitability  of  the  MetApps  prototype  applications 
themselves  and  the  component  library.  The  scope  of  this  work  concentrates  on  exploiting 
the  MetApps  stand-alone  prototype  applications  and  library  to  their  fullest  extent  through 
the  construction  of  two  experimental  applications.  In  order  to  do  this  in  the  most  efficient 
manner,  data  issues  (such  as  format)  had  to  be  addressed  first.  It  was  only  then  that  the 
remainder  of  this  thesis  could  concentrate  on  the  development  of  two  platform- 
independent  multi-use  applications  that  fully  exploit  the  capabilities  of  Unidata  MetApps. 

1 .4  Overview  of  Approach 

The  overall  approach  taken  in  this  thesis  was  one  of  software  reuse  and 
component-based  engineering.  Component-based  software  engineering  (or  CBSE)  is  a 
process  that  places  emphasis  on  the  design  and  construction  of  computing  systems  using 
reusable  software  components  (Pressman,  2000).  The  CBSE  approach  can  be  illustrated 
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by  thinking  of  it  in  terms  of  assembling  a  home  stereo  system  from  stereo  components. 
Assembly  of  a  system  is  easy  because  the  user  is  not  expected  to  build  the  system  from  a 
sundry  mix  of  transistors,  capacitors,  and  resistors.  The  stereo  user  may  purchase  his 
receiver,  turntable,  and  cassette  deck  from  different  manufacturers  and  assemble  them  at 
home  and  be  reasonably  confident  that  the  parts  will  work  together.  Component-base 
software  engineering  attempts  to  accomplish  this  same  result  with  software.  In  this 
thesis,  the  “components”  in  question  are  the  MetApps  stand-alone  prototypes  and  the 
classes  contained  in  the  MetApps  library.  The  impetus  behind  a  component-based  and 
re-use  approach  is  of  course  monetary.  Just  as  it  is  cheaper  to  purchase  stereo 
components  rather  than  to  design  and  build  them,  it  is  cheaper  to  reuse  software 
components  than  to  actually  write  the  components  oneself. 

The  analysis  and  design  phase  of  this  thesis  started  with  research  into  the 
background  of  software  systems  that  are  currently  used  to  deliver  user-customized 
aviation  weather  products  to  customers  worldwide.  Research  was  also  conducted  into 
what  already  has  been  done  in  the  area  of  component-based  software  development  in  the 
field  of  meteorology,  specifically  the  use  of  the  Java™  programming  language.  The 
question  of  how  the  meteorological  forecast  model  data  should  be  handled,  what  data- 
format  should  be  the  standard,  and  where  the  data  should  be  produced  was  addressed 
through  analysis  of  several  options.  Among  these  was  the  feasibility  of  raw-data 
conversion  by  the  user  and  the  Abstract  Data  Distribution  Environment  (ADDE)  client- 
server  type  architecture  to  obtain  data.  Next,  copies  of  IMAST  and  IGrADS  software 
were  obtained  from  AEWA  and  analyzed  with  particular  attention  paid  as  to  how 
IGrADS  is  designed,  hollowing  this  step,  analysis  of  how  Unidata  MetApps  is  structured 
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was  conducted  after  a  preliminary  review  of  Java™  syntax.  The  analysis  phase  was 
eompleted  by  eonstrueting  a  tentative  elass  diagram  and  system  design  of  viable  thesis 
prototype  interaetive  software  suite  using  TogetherSoft  software.  The  seeond  stage  was 
the  experimental  or  eoding  stage.  During  this  stage  two  experimental  approaehes  were 
implemented  through  the  eonstruction  of  two  separate  applieations.  The  first  of  these 
applieations  was  implemented  using  the  Faeade  software  design  pattern.  It  used  existing 
MetApps  stand-alone  prototype  applieations.  The  second  application  followed  a  hybrid 
Faeade/adapter  software  design  pattern,  exploiting  the  eapabilities  of  the  MetApps 
eomponent  library.  The  final  stage  of  this  researeh  eonsisted  of  testing  the  experimental 
applieations  using  available  netCDF  format  meteorologieal  model  data  files  available 
loeally  and  from  the  Internet  using  both  UNIX  workstations  and  Windows  PC’s.  The 
experiments  provided  valuable  information  regarding  the  suitability  of  MetApps  for 
ineorporation  in  operational  aviation  weather  produets  generation  software. 

1 .5  Organizational  Overview 

Chapter  two  eonsists  of  an  overview  and  discussion  of  related  work  in  the  area  of 
weather  data  visualization  tools.  The  tools  diseussed  are  not  just  those  used  by  the 
military,  but  also  those  used  in  the  aeademie  eommunity.  The  discussion  begins  with  one 
of  the  older  visualization  tools,  MelDAS,  and  ends  with  what  eould  be  deseribed  as  one 
of  the  most  cutting-edge  tools,  Java™-based  4DWX.  Chapter  three  deseribes  the 
experimental  methodology  used  in  the  preparation  of  this  thesis.  This  ineludes  details  on 
the  design  of  the  experimental  programming  environment  and  of  the  applieations 
developed  using  the  MetApps  stand-alone  prototypes  and  eomponent  library.  Chapter 
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four  discusses  exclusively  the  results  of  this  thesis  researeh.  Finally,  Chapter  five 
provides  some  eonclusions  and  makes  reeommendations  for  future  researeh.  Ineluded  at 
the  end  of  this  doeument,  as  Appendix  A,  is  a  list  of  eommon  acronyms  used  in  this 
thesis. 
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2.  Related  Work 


2.1  Overview 

There  has  been  widespread  use  of  various  meteorologieal  data  visualization  tools 
throughout  the  worldwide  meteorological  community.  Among  these  tools  the  most  well 
known  is  McIDAS,  the  Man-computer  Interactive  Data  Access  System,  which  is 
supported  by  Unidata.  Other  tools  used  to  construct  customized  meteorological  products 
include  the  primary  geophysical  dataset  visualization  tools  currently  employed  by  the  US 
Air  Force.  These  are  GrADS  (Grid  Analysis  and  Display  System)  and  Vis5D,  a  system 
for  interactive  visualization  of  large  five-dimensional  (5D)  gridded  data  sets.  On  the 
cutting  edge  of  the  development  of  geophysical  data  visualization  tools  are  projects  such 
as  VisAD  (Visualization  for  Algorithm  Development)  Java™  component  library  and 
MetApps,  which  employs  the  VisAD  library  heavily.  Lastly,  building  on  the  work  done 
with  VisAD  is  the  US  Army’s  4DWX  (Four-dimensional  Weather)  system,  which  is 
currently  under  development. 

2.2  McIDAS 

Developed  in  the  1970's,  to  fill  a  then  void  in  visualization  tools,  the  Man- 
computer  Interactive  Data  Access  System  (McIDAS)  was  revolutionary  in  that  it 
provided  the  capability  of  overlaying  data  from  diverse  sources.  For  example,  surface 
temperatures  could  relatively  easily  be  overlaid  on  a  satellite  image.  An  example  of  such 
a  product  is  shown  in  Figure  1  below.  McIDAS  was  also  the  first  tool  to  allow  the  user  to 
actually  display  meteorological  information  using  colors  and  animation.  McIDAS  has 
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Figure  1.  McIDAS  Product,  In  this  13  March  1993  (Blizzard  of  ’93)  image, 
McIDAS  was  used  to  overlay  temperature  contours  and  weather  data  plots  on  top  of 
enhanced  satellite  imagery  (Image  courtesy  of  SSEC,  1997). 


been  in  use,  and  under  continual  development  by  the  Space  Science  and  Engineering 
Center  (SSEC)  of  the  University  of  Wisconsin-Madison  since  1972.  The  McIDAS  of 
today  is  a  large,  research  quality,  suite  of  applications  used  for  decoding,  analyzing,  and 
displaying  meteorological  data  for  research  and  education.  The  software  can  be  used 
with  conventional  observational,  satellite,  and  grid-point  data. 

Unidata’s  distribution  of  McIDAS  (a  superset  of  SSEC  McIDAS)  has  been  under 
development  since  1985  and  in  distribution  since  1988.  Unidata  distributes  a  version  of 
McIDAS  known  as  McIDAS-X  (the  “X”  implying  a  requirement  for  X-Windows),  which 
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runs  on  a  variety  of  UNIX  platforms  (UCAR,  2001).  Many,  if  not  all,  later 
meteorological  visualization  tools,  such  as  GrADS  and  Vis5D,  owe  much  to  the 
groundbreaking  work  done  with  McIDAS.  McIDAS  was  the  first  so-called  truly  “user- 
friendly”  visual  meteorological  application. 

One  of  the  benefits  of  McIDAS  is  that  it  has  a  long  history.  McIDAS  has  been 
around  in  some  incarnation  since  1972  and  there  is  ample  documentation  for  virtually 
everything  that  can  possibly  be  done  with  the  McIDAS  software  suite.  It  is  by  all 
standards  a  true  classic  in  the  field  of  meteorological  visualization.  There  are  however 
many  drawbacks  to  McIDAS.  First,  it  is  not  small.  McIDAS  consists  of  over  one  and 
one-half  million  lines  of  code  contained  in  nearly  four  thousand  modules  (SSEC,  1997). 

It  can  occupy  as  much  as  one  gigabyte  of  hard  drive  space  not  including  any 
meteorological  data  files  (which  could  add  an  additional  gigabyte  or  two  to  the  hard  drive 
space  occupied).  Second,  McIDAS  only  runs  on  specific  UNIX  systems  running  X- 
Windows  and  is  thus  not  platform-independent.  Third,  McIDAS  is  not  self-contained. 

As  a  prerequisite  for  using  McIDAS,  a  variety  of  sundry  software  applications  and 
libraries  must  be  pre-installed  in  order  for  the  McIDAS  software  suite  to  operate 
correctly.  Last,  even  though  McIDAS  has  been  around  since  1972,  it  is  not  bug-free. 

One  of  the  more  annoying  of  these  bugs  is  the  fact  that  the  remote  serving  of 
meteorological  sounding  data  does  not  work  reliably  under  newer  versions  of  the  Linux 
operating  system. 
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2.3  GrADS 


The  Grid  Analysis  and  Display  System  (GrADS),  developed  by  Mr.  Brian  Doty  in 
conjunction  with  the  Center  for  Ocean-Land-Atmosphere  (COLA)  Studies,  is  an 
interactive  desktop  visualization  tool  that  is  used  for  easy  access,  manipulation,  and 
visualization  of  geophysical  data.  The  GrADS  visualization  tool  has  been  implemented 
worldwide  on  a  variety  of  commonly  used  operating  systems  and  is  freely  distributed 
over  the  Internet.  The  standard  way  of  using  GrADS  is  by  executing  operations 
interactively  by  entering  FORTRAN-like  expressions  on  a  command  line.  GrADS  does, 
however,  have  a  programmable  interface  in  the  form  of  a  scripting  language,  which 
allows  for  analysis  and  display  applications.  (COLA,  2001)  GrADS  scripts  may  display 
widgets  as  well  as  graphics.  One  of  the  common  ways  of  exploiting  this  GrADS  feature 
is  by  using  Athena  widgets  to  build  a  GrADS  GUI  (Graphical  User  Interface).  Examples 
of  how  to  use  GrADS  in  this  manner  can  be  found  on  the  NASA  Goddard  Space  Flight 
Center,  Data  Assimilation  Office  Web  pages  (DAO,  2001).  The  GrADS  scripting 
language  can  also  be  used  to  automate  complex  multi-step  calculations  or  displays 
(COLA,  2001).  In  the  case  of  the  Air  Force  Weather  Agency’s  Joint  Air  Force  and  Army 
Weather  Information  Network  (JAAWIN),  GrADS  has  been  used  to  produce 
visualizations.  These  visualizations  were  then  piped  via  the  Interactive  Meteorogram  and 
Skew-T  (IMaST)  system  back  to  the  user  who  requested  the  product.  IMaST  is  actually 
an  ingenious  JavaScript  interactive  interface  developed  by  the  Air  Force  Weather  Agency 
Technology  Exploitation  Branch  for  GrADS.  It  allows  a  user  to  produce  a  meteorogram, 
such  as  the  one  shown  in  Figure  2  below,  or  skew-T  diagram  (both  specialized 
visualizations)  for  any  location  within  the  domain  of  a  user-determined  meteorological 


13 


fright-Patterson  AFB,  OH 


RWY;  05/23 
Lol:  W 
Lot;  -84 


AFWA  Forecast  Meteoqram 
NCEP  MRF  Model  Cycle:  02JAN2002  OOZ 


9JAN  11JAN 


13JAN  15JAN  t7JAN 


PrecipitotiofP 

(inches) 

.1^,-!  0.14- 

Ra1n/Sno4,. 

Mixed,  Sleet 
Snow,  Roir  0-08- 
Showers/ 

TSTMS,  0'C4 

Ice/  0-^2  ■ 

Freezing  Rom 


lillilli 


7J14N  9  JAW  11  JAW  13JAN  15JAN  17JAN 


Figure  2,  GrADS  Meteorogram,  Depicted  here  is  a  meteorogram  produced  using 
GrADS  and  the  IMAST  interactive  user  interface.  These  products  can  he  custom 
huilt  using  a  customer’s  meteorological  model  and  location  specifications 
(Meteorogram  courtesy  of  Air  Force  Weather  Agency), 

forecast  model.  The  user  can  enter  either  map  coordinates,  a  4-letter  ICAO  (International 
Civil  Aviation  Organization)  identifier,  or  pick  a  location  on  a  number  of  theater  maps. 

On  the  positive  side,  GrADS  is  much  smaller  than  McIDAS  and  a  Wm32  port  of 
GrADS  has  been  developed  that  can  be  run  on  a  Windows  PC.  The  drawback  of  this 
Win32  port  is  that  one  must  have  an  X-server  running  in  order  to  display  graphics.  There 
is  also  a  Mac  version  of  GrADS  in  existence  but  neither  COLA  nor  any  other  entity 
supports  it.  GrADS  is  also  more  portable  than  the  McIDAS  application  suite  requiring  a 
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user  to  download  only  three  files  (besides  data  files).  It  also  has  the  powerful  eapability 
of  reading  GRIB  formatted  data  (one  of  the  more  popular  meteorologieal  data  formats) 
direetly.  Finally,  GrADS  is  well  doeumented  and  widely  used  among  meteorologists. 

On  the  down  side,  GrADS  is  eopyrighted  software,  and  although  the  souree  eode  is 
available,  it  is  subjeet  to  restrietions.  In  addition,  GrADS,  although  a  robust  applieation, 
is  not  platform  independent.  GrADS  requires  an  X-windows  server  to  funetion  eorreetly. 

2.4  Vis5D 

Vis5D,  used  widely  by  the  Air  Foree  Combat  Climatology  Center,  is  a  software 
system  that  ean  be  used  to  visualize  both  gridded  data  and  irregularly  loeated  data. 
Sourees  for  this  data  ean  eome  from  numerieal  weather  models,  surfaee  observations  and 
other  similar  sourees.  Vis5D  is  designed  to  work  with  data  in  the  form  of  a  five¬ 
dimensional  (5D)  reetangle.  In  other  words,  the  data  eonsists  of  real  numbers  at  eaeh 
point  on  a  "grid"  whieh  spans  three  spaee  dimensions,  one  time  dimension,  and  a 
dimension  for  enumerating  multiple  physieal  variables.  Vis5D  does  not  aetually 
“require”  the  use  of  a  5D  reetangle.  This  software  will  work  on  data  sets  with  only  one 
variable,  one  time  step  (i.e.  no  time  dynamies)  or  one  vertieal  level.  Vis5D  ean  also  work 
with  irregularly  spaeed  data,  whieh  are  stored  as  "reeords".  Eaeh  reeord  eontains  a 
geographie  loeation,  a  time,  and  a  set  of  variables,  whieh  ean  eontain  either  eharaeter  or 
numerieal  data. 

A  major  feature  of  Vis5D  is  support  for  eomparing  multiple  data  sets.  This  extra 
data  ean  be  ineorporated  at  run-time  as  a  list  of  “v5d”  files  or  imported  at  anytime  after 
Vis5D  is  running.  Data  ean  be  overlaid  in  the  same  3-D  display  and/or  viewed  side-by- 
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side  spreadsheet  style.  In  the  spreadsheet  style,  multiple  displays  can  be  linked.  Once 
linked,  the  time  steps  from  all  data  sets  are  merged  and  the  controls  of  the  linked  displays 
are  synchronized.  An  example  of  such  a  spreadsheet  display  is  shown  in  Figure  3  below. 
The  Vis5D  system  includes  the  vis5d  visualization  program,  several  programs  for 
managing  and  analyzing  five-dimensional  data  grids,  and  instructions  and  sample  source 
code  for  converting  data  into  the  native  Vis5D  file  format  (SSEC,  2000).  Vis5D 
visualizations  have  the  distinction  of  appearing  almost  identical  to  VisAD  visualizations, 
VisAD  being  one  of  the  required  sub-components  for  MetApps. 
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Figure  3,  VisSD  Screenshot,  This  screenshot  shows  VisSD  generating  a  spreadsheet 
display  of  four  memhers  of  an  ECMWF  ensemhle  forecast  (Image  courtesy  of 

SSEC,  1998). 
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Another  important  feature  of  Vis5D  is  the  Vis5D  API  (Applieation  Programmer's 
Interfaee).  This  API  is  an  interfaee  between  the  Vis5D  user  interfaee  and  the  Vis5D  eore 
software.  This  API  allows  developers  to  inelude  Vis5D  as  a  visualization  subsystem  of 
other  systems,  where  the  other  system  invokes  the  Vis5D  eore  through  the  API.  Thus 
one  ean  incorporate  the  functionality  of  Vis5D  into  the  user  interface  of  a  primary  system 
without  abandoning  the  user-interface  style  of  that  primary  system. 

Among  the  drawbacks  of  Vis5D  is  the  fact  that,  like  GrADS,  it  is  protected  by 
copyrights.  It  is  also  not  platform- independent,  the  code  having  been  written  in  the  C 
(like  GrADS)  and  the  FORTRAN  programming  languages.  Finally,  Vis5D  development 
has  ceased  at  the  Space  Science  and  Engineering  Center  (SSEC)  even  though  the  latest 
version  of  the  software  is  available  on  the  SourceEorge  Vis5d+  Internet  site 
(SourceEorge,  2001).  SSEC  has  chosen  instead  to  concentrate  its  resources  on  the  further 
development  of  VisAD,  the  Java™  incarnation  of  Vis5D. 

2.5  VisAD 

The  word  “VisAD”  is  an  acronym  for  "Visualization  for  Algorithm 
Development".  VisAD  is  a  Java™  component  library  (consisting  of  a  package  of  Java™ 
classes)  providing  support  for  interactive  and  collaborative  visualization  and  analysis  of 
numerical  scientific  (especially  geophysical)  data.  The  library  was  created  and  is  actively 
being  developed  by  the  Space  Science  and  Engineering  Center  (SSEC)  at  the  University 
of  Wisconsin.  VisAD  provides  the  building  blocks  (or  components)  for  application 
developers  to  more  easily  create  scientific  applications  using  the  Java™  programming 
language.  The  VisAD  library,  however,  is  not  and  was  never  intended  to  be  a  stand-alone 
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application.  Nevertheless,  ineluded  with  VisAD  are  a  number  of  experimental 
applieations  that  exploit  the  features  of  its  eomponent  library.  Among  these  is  the  VisAD 
Spreadsheet  applieation  (a  screenshot  of  which  is  shown  in  Figure  4). 
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Figure  4.  VisAD  Screenshot,  This  screenshot  shows  a  visualization  spreadsheet 
application  huilt  using  the  VisAD  library.  Of  note  are  the  similarities  in  appearance 
to  VisSD  imagery  and  color  schema  (Image  courtesy  of  SSEC,  2001), 


VisAD  has  become  the  backbone  of  the  MetApps  and  4DWX  visualization 
systems  (both  discussed  later  in  this  chapter).  The  question  is  why.  Why  would  the 
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developers  of  MetApps  and  the  Army’s  4DWX  systems  seleet  the  VisAD  eomponent 
library  to  visualize  their  meteorologieal  model  data?  There  are  aetually  four  important 
factors  (or  reasons)  that  lead  to  the  natural  selection  of  VisAD  as  part  of  a  visualization 
solution. 

The  first  factor  is  the  VisAD  library’s  platform  independence  and  open  source 
licensing.  The  VisAD  system  uses  pure  Java^'^  for  platform  independence  and  to  support 
data  sharing  and  real-time  collaboration  among  geographically  distributed  users.  This  fits 
in  well  with  the  goals  of  many  current  and  future  Java™  software  development  projects 
and  makes  way  for  interactivity  via  the  Web.  By  necessity,  Java™  code  is  object- 
oriented  thus  promoting  extensibility  and  code  reuse,  which  drives  down  the  cost  of 
development.  In  addition,  the  VisAD  code  is  open  source  Lesser  GNU  Public  License 
(LGPL).  Anyone  can  use  the  code  or  contribute  to  it.  As  a  result  there  is  a  very 
supportive  community  that  correct  problems  and  add  features  to  the  library  regularly. 

The  second  factor  has  to  do  with  the  VisAD  data  model.  VisAD  incorporates  a 
general  mathematical  data  model  that  can  be  adapted  to  virtually  any  set  of  numerical 
data,  which  supports  data  sharing  among  different  users,  different  data  sources,  and 
different  scientific  disciplines.  This  provides  access  to  data  that  is  independent  of 
storage-format  and  location.  The  VisAD  mathematical  data  model  has  been  adapted  to 
many  file  formats  one  of  which  is  netCDF  (network  Common  Data  Form),  which  is  the 
primary  data  format  used  by  MetApps.  Another  aspect  of  the  data  model  is  internal 
representation  of  data.  One  particular  data  set  might  have  a  one -kilometer  resolution 
while  another  has  a  four-kilometer  resolution.  One  domain  might  be  defined  by  equal 
spacing  from  a  given  location  while  another  has  an  irregular  longitude-latitude  grid.  One 
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sensor  might  provide  temperature  in  Celsius  while  another  reports  in  Fahrenheit.  One 
model  might  provide  upper  air  data  on  pressure  levels  while  another  provides  height 
above  ground.  Designing  and  implementing  a  software  data  structure  to  deal  with  these 
disparities  is  a  monumental  task.  VisAD  provides  a  solution  to  the  problem  of  designing 
and  implementing  a  software  data  structure  to  deal  with  data  differences.  It  provides  a 
sophisticated  data  model  that  allows  an  application  developer  to  represent  many  different 
types  of  data  in  a  consistent  manner.  (Lindholm,  2001) 

The  third  factor  is  the  VisAD  display  system.  VisAD  utilizes  a  general  display 
model  that  supports  three-dimensional  (3D)  interactivity,  data  fusion,  multiple  data 
views,  direct  manipulation,  collaboration,  and  virtual  reality.  VisAD  offers  the 
application  developer  a  simple  interface  for  displaying  data  while  hiding  the  complexities 
of  creating  graphics.  Data  can  be  displayed  as  lines,  points,  images,  contours,  or 
customized  shapes.  The  software  developer  also  has  control  of  display  properties  such  as 
data  ranges,  color,  and  line  width.  Animation  support  is  also  included.  A  3D  view  can 
be  obtained  by  mapping  a  field  (such  as  altitude)  to  the  Z-Axis.  The  user  can  rotate, 
zoom,  and  pan  the  scene.  VisAD  also  provides  a  direct  manipulation  mechanism.  A  user 
can  "grab"  the  data  on  the  display  with  the  mouse  and  move  or  redraw  it.  As  a  result,  the 
underlying  data  object's  data  values  will  be  changed.  (Lindholm,  2001) 

The  fourth  factor  is  that  support  for  two  distinct  communities  is  built-in: 
developers  who  create  domain-specific  systems  based  on  VisAD,  and  users  of  those 
domain-specific  systems.  Because  of  the  way  VisAD  is  designed,  it  supports  a  wide 
variety  of  user  interfaces,  ranging  from  simple  data  browser  applets  to  complex 
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applications  that  allow  groups  of  scientists  to  collaboratively  develop  data  analysis 
algorithms.  VisAD  provides  for  developer  extensibility  in  as  many  ways  as  possible. 

All  these  faetors  lead  one  to  the  unmistakable  eonelusion  that  VisAD  provides  an 
abundanee  of  data  visualization  and  analysis  funetionality  greatly  enhaneing  an 
applieation  developer's  ability  to  ereate  powerful  seientific  applieations  while  affording 
the  flexibility  for  customization. 

2.6  MetApps 

In  academia,  as  previously  mentioned,  the  University  Corporation  for 
Atmospherie  Researeh  (UCAR)  Unidata  Program  Center  has  over  the  past  four  years 
coordinated  the  development  of  Meteorologieal  Applications  (MetApps),  a  platform- 
independent  meteorologieal  software  suite  and  visualization  tool  eonsisting  of  a  set  of 
object-oriented  Java™  classes  and  abstract  data  types  (Caron,  1999).  The  goal  of  the 
MetApps  project  is  for  MetApps  to  operate  both  as  a  stand-alone  applieation  (or  set  of 
applieations)  and  as  part  of  larger  distributed  elient  server  arehiteetures  that  enable 
growth  in  both  functionality  and  the  number  of  user  workstations  (UCAR,  2000). 
MetApps  software  is  freely  available  and  is  proteeted  under  the  Lesser  GNU  Publie 
Lieense  (LGPL),  whieh  means  that  MetApps  ean  be  tailored  to  meet  individual 
programmers’  needs.  The  MetApps  prototype  applieations  that  have  been  developed  up 
to  this  point  are  designed  to  run  on  any  platforms  that  fully  support  Java™  2  and  Java 
3D™.  Currently,  the  MetApps  prototypes  are  being  tested  mainly  on  the  Windows, 
Solaris,  and  Linux  platforms.  Shown  in  Figure  5  is  a  sereenshot  of  the  MetApps  Gridded 
Data  Viewer  (GDV),  the  most  reeently  developed  prototype  applieation.  Amply  evident 
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is  the  use  of  VisAD  library  display  eomponents  to  generate  an  interaetive  meteorologieal 
produet.  The  VisAD  Java^"^  library  is  required  for  most  of  the  MetApps  eomponents. 
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Figure  5.  MetApps  Screenshot,  This  screenshot  shows  the  MetApps  3D  Gridded 
Data  Viewer  (GDV)  showing  -25°C  temperature  isosurface.  The  use  of  VisAD 
library  components  should  he  apparent  in  the  creation  of  the  image  portion  of  the 

display  (refer  to  Figure  4), 


MetApps  is  a  work  in  progress  and  part  of  the  ongoing  researeh  sponsored  by 
Unidata.  This  means  that  the  classes  contained  in  the  MetApps  library  are  in  a  state  of 
flux.  Changes  and/or  “improvements”  to  the  library  should  be  expected.  While  some 
parts  of  it  have  stabilized  for  now  (such  as  netCDF  for  Java™)  others  remain  volatile 


22 


(such  as  VisAD,  which  is  undergoing  continual  development).  A  more  extensive  analysis 
of  the  design  and  capabilities  of  the  MetApps  prototype  applications  and  library  are 
provided  in  Appendix  B  of  this  thesis.  The  development  of  MetApps  has  not  gone 
unnoticed.  Beeause  of  the  lower  costs  involved  in  reusing  software  components  to 
develop  applications,  much  interest  has  been  shown  in  MetApps  by  developers  outside  of 
the  aeademie  research  community.  In  this  thesis,  efforts  concentrate  on  determining  the 
feasibility  of  MetApps  for  ineorporation  into  a  system  for  providing  user-eustomized 
aviation  weather  produets  in  an  operational  rather  than  in  a  researeh  environment. 

2.7  4DWX 

Back  in  the  military  community,  completely  independent  from  current  Air  Force 
Weather  Agency  efforts,  researeh  has  been  condueted  into  a  Java™  implementation  of 
meteorologieal  visualization  tools  under  the  aeronym  4DWX.  The  concept  for  the  Four- 
Dimensional  Weather  (4DWX)  System  originated  in  the  recommendations  of  a  study 
commissioned  in  1995  by  the  Atmospheric  Sciences  Division  (now  Atmospherie 
Sciences  Braneh)  at  Headquarters,  U.S.  Army  Test  and  Evaluation  Command  (ATEC). 

At  the  time,  the  Atmospheric  Sciences  Braneh  reeognized  that  the  U.  S.  Army  Test  and 
Evaluation  Command  meteorological  support  function  had  to  change  its  way  of  doing 
business  if  it  was  to  help  meet  the  ehallenge  of  testing  new  and  more  eomplex  materiel, 
sueh  as  smart  munitions,  at  a  time  of  declining  resources  for  test  and  evaluation.  The 
National  Center  for  Atmospherie  Researeh  (NCAR)  found  that  the  Army  Test  and 
Evaluation  Command  was  not  making  full  use  of  its  meteorological  information  because 
of  problems  in  four  areas:  data  base  management,  data  assimilation,  modeling,  and  user 
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displays  (Bowers,  2000).  NCAR  also  recommended  a  set  of  solutions  to  the  identified 
meteorological  support  problems.  Promoting  the  concept  of  software  reuse,  wherever 
possible,  the  recommended  solutions  were  based  on  existing  software,  including  the 
NCAR/Penn  State  non-hydrostatic  Mesoscale  Model  Version  5  (MM5),  the  Zebra  data 
archival  and  display  system  (developed  by  the  NCAR  Research  Data  Program),  and  the 
thunderstorm  AutoNowcaster  algorithm.  The  Atmospheric  Sciences  Branch  decided  to 
proceed  in  Fiscal  Year  1997  with  the  development  of  a  prototype  4DWX  system  to 
implement  NCAR's  recommendations.  (ATEC,  2001) 

As  part  of  4DWX,  the  Visual  Meteorology  Tool  (VMET)  was  developed  as  the 
versatile  display  component  of  the  4DWX  system.  It  was  designed  to  enhance  the 
forecast  and  research  meteorologist's  ability  to  visualize,  explore,  manipulate,  and 
analyze  meteorological  model  data  sets  in  two,  three,  and  four  dimensions.  VMET  can 
also  serve  as  a  virtual  environment  in  which  to  run  virtual  experiments  in  real  weather. 

In  addition,  VMET  is  written  entirely  in  Java^'^  and  built  upon  the  VisAD  libraries. 
Easily,  VMET  can  integrate  a  variety  of  data  sets  into  a  single  interactive  two  or  three- 
dimensional  display  (NCAR,  2001).  A  screenshot  of  VMET  is  shown  in  Eigure  6.  It  is 
apparent  from  the  screenshot  that  like  the  MetApps  Gridded  Data  Viewer,  VMET  owes  a 
lot  of  its  visualization  functionality  to  the  VisAD  library. 

The  4DWX  program,  however,  was  not  without  its  problems.  The  program 
included  a  groundbreaking  attempt  at  using  a  database  to  manage  most  of  the  primary 
data  in  a  major  operational  system.  At  the  start  of  the  program,  the  plan  was  to  apply  the 
latest  database  technologies  to  all  of  the  data  sets,  including  the  large  3D  output  volumes 
generated  by  the  MM5  meteorological  forecast  models.  After  a  period  of  extensive 
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Figure  6,  4DWX  VMET  Screenshot.  This  screenshot  shows  an  example  of  an 
application  composed  of  multiple  4DWX  VMET  components  combined  with  Java™ 
Swing  components.  This  application  hears  many  similarities  to  the  MetApps 
Gridded  Data  Viewer  prototype  application  shown  in  Figure  5,  a  direct  result  of  the 
wide  use  of  the  VisAD  component  library  (Image  courtesy  of  UCAR,  2001). 


testing,  it  was  determined  that  performance  issues  and  implementation  complexity  called 
for  a  scaled-down  plan  for  the  database,  restricting  it  to  the  collection  of  measured 
observation  data  sets  needed  in  the  4DWX  system  (NCAR,  2000). 


2,8  Summation 

In  the  end,  the  very  existence  of  MetApps  and  4DWX  is  important  to  this  thesis 
research.  The  development  of  projects  such  as  MetApps  in  the  civilian  and  4DWX  in  the 
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military  community  shows  that  the  cutting  edge  developments  in  meteorologieal 
visualization  almost  exelusively  rely  on  eomponent-based  solutions  and  the  Java™ 
programming  language.  Today  more  applications  than  ever  must  interface  with  the 
Internet,  and  Java™  is  the  natural  solution.  Apart  from  being  the  preeminent  language 
of  the  Internet,  Java™  is  important  for  other  reasons  not  the  least  of  whieh  is  that  it  has 
altered  the  way  in  whieh  we  program  eomputers.  Java^”^  has  eome  a  long  way  from  its 
early  days  as  a  platform-independent  language  that  eould  be  used  to  ereate  software  for 
embedding  in  eonsumer  produets  sueh  as  mierowave  ovens.  The  Internet,  with  its 
dynamie  environment  and  wide  variety  of  different  eomputing  platforms,  helped  eatapult 
Java™  to  the  forefront  of  programming  today  making  it  in  many  oases  the  language  of 
ohoioe.  Compared  to  the  other  mainstream  oomputer  languages  of  today,  sueh  as  C,  C++, 
and  FORTRAN,  it  is  only  in  speed  and  performanoe  where  Java^'^  lags  behind.  But  even 
here,  Java™  is  oatching  up  rapidly  (Sohatzman,  2001). 
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3.  Methodology 


3.1  Overview 

This  chapter  provides  a  detailed  description  of  the  approaches  used  in 
aceomplishing  this  thesis.  A  description  of  the  high  and  low-level  goals  and  the  eriteria 
for  success  are  provided.  Next  is  a  description  of  the  experimental  software  and 
hardware  environments  for  the  experiments  performed  in  this  thesis.  These  environment 
deseriptions  are  followed  by  an  explanation  of  two  separate  experimental  approaehes. 

The  first  approach  depends  on  the  stand-alone  MetApps  applieations  while  the  second 
utilizes  the  MetApps  library.  Rounding  off  this  chapter  is  a  section  dealing  with  the 
important  issue  of  data  requirements  and  handling.  This  last  section  is  important  since  a 
measure  of  sueeess  of  this  project  can  be  measured  by  how  well  Unidata  MetApps  deals 
with  the  meteorologieal  data  issues. 

3.2  Goals 

The  guiding  goal  for  this  thesis  is  to  find  a  multi-purpose  interactive  military 
aviation  weather  product  generation  software  solution.  This  software  solution  must  be 
platform-independent,  multiple  data  source  aceess  eonfigurable,  robust,  extensible  or 
upgradeable,  user-friendly,  and  an  improvement  over  eurrent  visualization  applications 
used  in  the  operational  military  aviation  weather  community.  Another  goal  is  to 
determine  if  a  software  reuse  and  component  library-based  approaeh  ean  be  used  in  sueh 
a  solution.  A  sub  goal  of  this  is  to  determine  whether  the  Java™-based  Unidata  MetApps 
components  are  suitable  for  fulfilling  this  software  component  library  role.  A  final  sub 
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goal  is  to  provide  a  realistic  assessment  that  can  be  used  to  determine  if  Department  of 
Defense  (DoD)  funds  should  be  diverted  into  the  development  of  meteorological 
visualization  software  based  on  Unidata  MetApps  rather  than  in-house  DoD  projects. 

3.3  Requirements  for  Success 

The  requirements  for  success  of  the  software  solution  are  six-fold  and  largely 
objective.  The  first  of  these  requirements  is  that  the  software  solution  developed  using 
the  existing  components  be  platform-independent.  Due  to  the  unpredictable  nature  of 
worldwide  military  operations,  identical  software  platforms  at  diverse  geographically 
separated  locations  cannot  and  should  not  be  expected.  In  a  deployed  situation,  military 
weather  personnel  cannot  be  guaranteed  a  particular  “standard”  computing  environment. 
The  results  achieved  using  the  selected  software  solution  on  a  Sun  Solaris  workstation 
should  be  virtually  identical  to  those  achieved  on  a  Windows  PC.  Second,  the  software 
solution  must  not  be  restricted  to  obtaining  data  from  a  single  source,  as  has  been  the  case 
in  the  past.  A  single  data  source  for  meteorological  data  creates  an  opportunity  for  one’s 
adversaries  to  undermine  the  capability  of  commanders  to  obtain  the  most  current 
aviation  weather  information.  Multiple  configuration  options  on  a  selected  software 
solution  should  effectively  mitigate  or  eliminate  this  problem.  Third,  the  solution  must 
be  robust.  35  megabyte  (MB)  Nested  Grid  Model  (NGM)  Grid  in  Binary  (GRIB)  files,  6 
MB  McIDAS  AREA  files,  and  2  MB  upper  air  files  should  be  considered  “normal”-sized 
data  files.  “Normal”  data  files  should  be  able  to  be  run  on  a  component-based  application 
without  putting  undue  strain  on  a  mid-level  Windows  PC  or  an  average  UNIX 
workstation.  Most  meteorological  personnel  have  limited  experience  in  dealing  with 
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software  problems.  Under  operational  eonditions  they  should  not  be  required  to 
eonstantly  “fix”  bugs  in  their  software  systems.  Fourth,  the  solution  must  be  extensible 
or  upgradeable.  The  reason  for  this  is  eost.  It  is  usually  eheaper  to  make  upgrades  or 
adaptations  rather  than  to  replaee  an  entire  system.  An  applieation  built  using  reusable 
eomponents  should  be  easier  to  upgrade  and  adapt  sinee  components  can  be  selectively 
replaced.  Fifth,  the  software  solution  should  be  user-friendly.  Although  this 
requirement/criteria  is  somewhat  subjective,  it  must  be  kept  in  mind  that  users  naturally 
will  avoid  software  that  is  difficult  to  use.  Military  users  should  be  capable  of 
interactively  generating  their  own  user-customized  aviation  weather  products  upon 
demand.  Sixth,  the  selected  software  solution  must  be  an  improvement  over  current 
visualization  applications  used  in  the  operational  aviation  weather  environment.  This  last 
requirement  may  prove  difficult  to  measure  or  fulfill.  The  simplest  way  to  make  this 
determination  is  to  make  a  subjective  comparison  between  any  new  solution  and  the 
GrADS  solution  currently  used  by  Air  Force  weather.  Considerable  operational 
experience  has  been  built  up  over  the  years  with  applications  such  as  GrADS.  The 
GrADS  software  application  has  the  capability  to  display  time  series  and,  through  scripts, 
meteorograms.  Most  component  libraries  have  yet  to  incorporate  such  functionality. 

3.4  Design  of  Experimental  Applications 

3.4.1  Overview 

The  experimental  approach  taken  in  this  thesis  involves  the  construction  of  two 
experimental  applications.  These  applications  demonstrate  and  test  the  functionality  of 
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the  software  components  in  question  and  determined  their  actual  level  of  functionality. 
The  premise  of  this  thesis  is  that  Unidata  MetApps  is  suitable  for  fulfilling  the  role  of  the 
component  library  used  in  developing  the  operational  application  that  fulfils  the 
requirements  set  forth  in  the  previous  section.  A  two-pronged  approach  is  taken  based  on 
the  premise  that  there  are  actually  two  types  of  MetApps.  The  first  MetApps  is  literally, 
as  the  acronym  implies,  composed  of  meteorological  applications.  The  second  MetApps 
is  a  Java^'^  class  library.  Thus,  the  two  experimental  applications  constructed  in  this 
research  are  based  on  the  duality  of  the  MetApps  project.  Both  experiments  use  a 
component-based  approach  to  the  construction  of  the  experimental  applications.  In 
traditional  object-oriented  programming  the  software  reuse  is  primarily  achieved  through 
inheritance  of  classes,  while  in  a  component-based  approach  reuse  is  achieved  through 
interfaces  with  independently  developed  software.  Therefore,  the  use  of  a  component- 
based  approach  does  not  preclude  one  from  applying  object-oriented  principles.  The 
component-based  approach  is  similar  to  construction  of  computer  system  hardware  from 
its  constituent  parts  (a  CPU  from  Intel,  a  soundcard  from  Creative,  memory  modules 
from  Samsung,  etc.)  or  to  putting  together  a  stereo  system,  as  previously  mentioned. 

A  component-based  approach  is  chosen  because  whether  VisAD,  MetApps,  or 
some  other  library  is  used,  one  is  still  essentially  dealing  with  the  assembly  of 
components  to  build  applications  or  systems.  By  concentrating  on  component 
architecture  one  can  separate  a  system  or  application  into  independent  subsystems. 
Particular  subsystems  can  then  be  manipulated,  changed,  or  adapted  at  the  discretion  of  a 
developer  with  minimal  impact  on  the  system  as  a  whole.  Lastly,  using  a  component- 
based  approach  on  both  of  the  experiments  provides  comparison  and  contrast.  This  gives 
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a  method  to  determine  whether  the  prototype  applieations  or  the  library  are  better  suited 
to  the  goals  of  this  thesis. 


3.4.2  Applieation  Design  Approaeh  1 

The  design  approaeh  ehosen  for  the  first  experimental  applieation  resembles 
elosely  the  Faeade  software  design  pattern.  Figure  7  shows  a  mueh-simplified  view  of 
the  Facade  software  design  pattern.  The  purpose  of  the  Facade  pattern  is  to  shield  a 
software  developer  from  the  possibly  large  amount  of  recoding  involved  in  an  application 
due  to  interface  changes  in  a  subcomponent.  An  object’s  interface  describes  the  complete 
set  of  requests  that  can  be  sent  to  that  object.  The  Facade  provides  a  unified  interface  to  a 


Figure  7,  Standard,  simplified  view  of  the  Facade  software  design  pattern.  Adapted 
from  an  original  diagram  by  Shalloway  and  Trott  (Shalloway  and  Trott,  2002). 
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set  of  interfaces.  The  motivation  behind  using  this  design  pattern  is  that  it  helps  reduce 
complexity  and  minimizes  the  task  of  tracking  down  every  call  to  an  interface.  Using  a 
Facade  pattern  promotes  weak  coupling  (Gamma,  1995).  Weak  coupling  makes  it  easier 
to  replace  or  change  subcomponents  without  disabling  the  complete  system.  The  biggest 
drawback  to  using  a  Facade-type  pattern  is  that  it  results  in  a  system  that  is  slower  and 
harder  to  understand  (Vlissides,  1996).  The  reason  for  this  is  that  the  Facade  adds 
additional  call  levels  to  a  software  system. 

The  first  experimental  application  in  this  research  uses  the  existing  stand-alone 
prototype  applications  contained  in  the  component  library,  in  this  case  MetApps.  An 
interface  is  required  that  links  the  library’s  existing  prototype  applications  together  in  a 
single  application.  This  interface  accesses  the  necessary  compiled  classes  in  the 
application  libraries  to  achieve  what  appears  as  a  seamless  integration  of  the  parts.  In 
addition,  a  number  of  other  library  files  are  required  for  the  applications  to  function 
properly.  A  complete  listing  of  these  required  libraries  is  provided  in  the  detailed 
description  of  MetApps  contained  in  Appendix  B.  It  should  be  pointed  out  that  some 
prototype  applications  do  not  have  any  additional  library  requirements.  The  MetApps 
Interactive  Sounding  Application  in  this  design  approach  as  depicted  in  Figure  8,  is 
completely  self-contained  and  has  no  special  requirements  except  a  Java™  runtime 
environment  (JRE).  The  Interactive  Sounding  Application  does  not  require  the  use  of 
additional  libraries  because  the  classes  it  requires  from  those  libraries  are  packaged 
together  with  the  sounding  classes.  Each  tabbed  rectangular  box  in  Figure  8  represents  a 
library  or  package.  The  dashed  arrows  show  how  some  libraries,  or  packages,  depend  on 
other  libraries.  For  example,  the  Image  Viewer  Application  depends  on  the  JavaHelp™ , 
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VisAD,  MetApps,  and  Data  Files  packages/libraries  to  function  properly.  The  bold 
dashed  enelosure  shows  what  is  required  for  the  GDV  while  the  bold  dotted  enelosure 
shows  the  Image  Viewer  requirements.  It  should  be  apparent  from  Figure  8  that  the 
MetApps  prototype  applieations  are  dependent  on  a  eore  set  of  shared  elasses  eontained 
in  a  set  of  libraries. 


In  the  ease  of  MetApps,  the  Faeade -based  approaeh  has  a  number  of  advantages, 
but  also  some  disadvantages.  One  advantage  is  that  with  the  exeeption  of  the  graphical 
user  interfaee,  it  is  expeeted  that  pre-eompiled  Java™  byteeode  ean  be  used  without 
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significant  problems.  The  interface  would  have  to  be  erafted  using  some  type  of 
interactive  development  environment  or  IDE.  Among  the  advantages  is  that  there  is  less 
depreeation  in  stand-alone  applieations.  Deprecation  is  what  happens  to  functions  when 
they  are  retired.  When  a  function  is  deprecated,  it  means  that  the  method  was  onee  valid, 
but  has  now  been  replaeed  by  a  newer  method.  Deprecation  is  a  problem  with  MetApps 
because  required  external  libraries,  sueh  as  VisAD,  are  updated  frequently.  This  problem 
is  not  unique  to  MetApps.  It  is  a  problem  with  most  software  projeets  that  depend  on 
components  that  have  been  developed  independently  from  said  project.  The  problem  can 
be  eliminated  by  eopying  the  offending  library  into  the  actual  application,  thereby 
shielding  the  application  from  unforeseen  ehanges  in  the  component  library.  Another 
possible  advantage  of  this  particular  design  approach  is  the  modularity  of  this  design.  In 
theory,  when  new  stand-alone  applieations  are  created  they  can  be  added  with  minimal 
rewriting  of  existing  applieation  code.  One  of  the  drawbacks  to  this  experimental 
applieation  design  is  that  it  is  difficult  to  make  even  small  changes  to  the  inner  workings 
of  the  individual  MetApps  stand-alone  applications  unless  the  source  eode  has  been  made 
available.  These  parts  of  the  application  are  by  definition  “self-eontained.” 


3.4.3  Applieation  Design  Approaeh  2 

The  second  experimental  design  approaeh  is  similar  to  the  first.  This  approach 
somewhat  resembles  the  Facade  software  design  pattern  deseribed  previously  above. 
However,  the  design  pattern  more  closely  resembles  a  hybrid  of  both  the  Facade  and 
Adapter  software  design  patterns.  The  purpose  of  an  Adapter  pattern  is  to  eonvert  the 
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interface  of  a  class  into  another  interface.  In  other  words,  a  new  interface  is  constructed 
for  an  object  that  works  correctly  but  has  the  “wrong”  interface.  In  this  approach  the 
actual  component  class  library  is  used  rather  than  precompiled  prototype  applications.  In 
this  design  an  application  is  constructed  using  the  base  classes  contained  within  the 
component  library.  Instead  of  an  application  interface,  this  design  depends  on  an 
application  class  that  depends  on  the  component  classes.  Unidata  has  indicated  that  in 
order  to  use  the  MetApps  library  in  this  manner  the  additional  libraries  of  JavaHelp^'^, 
VisAD,  and  the  Data  Files  must  be  included  in  any  Java™  project.  A  decision  was  made 
to  not  include  the  netCDF-2  Java™  library  and  instead  allow  for  dependence  of  the 
MetApps  classes  on  the  internal  version  of  netCDF-2.  This  was  a  logical  step  since  the 
internal  version  of  netCDF-2  is  virtually  identical  to  the  current  official  netCDF-2  Java™ 
library.  Preliminary  analysis  of  the  MetApps  library  in  the  course  of  this  research 
indicates  that  there  are  a  number  of  other  libraries  that  are  required  for  construction  of 
MetApps-based  applications.  Table  3  below  lists  these  additional  libraries. 


Table  1,  Additional  Libraries  Required  for  Design  Approach  2 


Library 

Filename 

JNLP 

j  nip  jar 

HTTP  Client 

HTTPClient.jar 

Data 

data.jar 

Units 

units  .jar 
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The  jnlp.jar  file  provides  support  for  Java™  Network  Launch  Protocol  (JNLP). 
JNLP  allows  a  user  to  run  a  Java™  application  or  applet  directly  from  the  Internet.  JNLP 
provides  direct  access  to  Java™  software  using  the  latest  Java^'^  virtual  machine  (or 
JVM)  without  the  constraints  and  problems  of  Java™  applets  within  web  browsers.  The 
HTTPClient.jar  TpackagQ  provides  a  complete  HTTP  (Hypertext  Transfer  Protocol)  client 
library.  The  data.jar  file  contains  some  additional  ancillary  files.  Lastly,  units.jar  is 
actually  a  sub-package  of  the  MetApps  library.  It  is  included  in  this  experimental  design 
to  help  determine  if  separating  the  sub-components  of  MetApps  results  in  a  more  robust 
application.  Figure  9  shows  how  the  MetApps  component  library  depends  on  all  the 
different  libraries  described  above.  What  is  not  shown  in  Figure  9  is  that  there  are 
dependencies  between  these  individual  libraries  as  well  (too  numerous  to  depict). 
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Figure  9,  Application  2  Diagram,  This  figure  depicts  a  mixed  class/package 
diagram  showing  the  relationships  between  the  experimental  application  and 
libraries  in  building  applications  using  Approach  2. 
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The  end  result  of  the  seeond  design  approaeh  should  mimio  the  results  aehieved 
by  the  first  design  approaeh  although  it  is  suspeeted  that  this  approaeh  has  greater 
stability.  The  reason  for  this  inereased  stability  is  that  in  this  approaeh  we  build  an 
applieation  using  all  souree  eode  rather  than  a  eombination  of  souree  and  eompiled 
byteeode.  An  additional  benefit  of  this  design  is  that  a  developer  has  greater  control  of 
how  his  or  her  application  behaves.  Minor  changes  to  the  code  can  easily  be  made 
without  resorting  to  de-compilation  of  the  original  Unidata  MetApps  Java^'^  bytecode. 
One  foreseeable  drawback  to  this  approach  is  the  inevitable  deprecation  of  some  of  the 
older  component  classes  that  depend  so  heavily  on  Vis  AD.  Problems  are  foreseen  with 
compilation  of  an  Interactive  Sounding  Application  since  it  depends  so  heavily  on  the 
VisAD  library.  The  VisAD  library  has  undergone  considerable  change  since  the  original 
Interactive  Sounding  Application  was  released  with  an  early  version  of  VisAD.  This 
problem  with  deprecation  could  possibly  negate  any  increase  in  application  stability 
achieved  through  the  use  of  source  code  compilation. 

3.5  Experimental  Programming  Environment  Setup 

Table  2  shows  the  setup  of  the  experimental  software  environment  for  this  thesis. 
MetApps,  which  is  theorized  to  fulfill  the  criteria  described  in  section  3  above,  is 
designed  to  run  on  any  platforms  that  fully  support  Java^'^  2  and  Java  3D^'^.  Java™  2 
Platform,  Standard  Edition  (J2SE)  provides  the  foundation  for  the  construction  of  the 
Java™  applications  in  this  thesis.  The  J2SE  is  implemented  by  the  Java™  2  Software 
Development  Kit  (SDK),  Standard  Edition,  and  the  Java™  2  Runtime  Environment 
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(JRE),  Standard  Edition.  The  J2SE  is  needed  to  run  the  MetApps  applieations.  This 
thesis  used  the  latest  version  of  Java™  2  from  Sun  Mierosystems  (version  1.3.1). 


Table  2,  Experimental  Software  Environment 


Software 


Java™  2  Platform,  Standard  Edition  (J2SE) 

Software  Development  Kit  (SDK)  1.3.1 

Java  3D™  Software 

Java  3D™  API  version  1 .2. 1  (either  OpenGL  or  DirectX  version). 


Various  Sundry  Packages 

JavaHelp^*'^:  A  full-featured,  platform-independent,  extensible  help  system  that 
enables  developers  and  authors  to  incorporate  online  help  in  applets,  components, 
applications,  operating  systems,  and  devices.  It  is  being  used  as  the  interface  to  the  on¬ 
line  documentation  for  the  MetApps  prototypes. 

VisAD:  A  Java™  class  library  for  interactive  and  collaborative  visualization  and 
analysis  of  numerical  data.  Its  data  model  and  display  capabilities  are  being  used  in 
several  of  the  MetApps  components  and  prototypes. 

MetApps:  A  standard  library  of  classes  developed  by  Unidata  (in  bytecode). 

Ancillary  Data  Files:  Ancillary  data  files  (icons,  enhancements,  map  files)  used  by 
the  MetApps  components  and  prototype  applications. 

Java™  Development  Environment 

Borland  JBuilder  5  Professional:  Visual  Java™  2  development  environment. 


Unidata  recommends  that  Solaris  users  install  a  number  of  system  patches  for 
Java™  2  to  work  correctly  (UCAR,  2000).  Preliminary  experimentation  with  the 
MetApps  prototypes,  by  the  author  of  this  thesis,  indicates  that  these  software  patches  are 
necessary  for  the  stability  of  the  MetApps  applications  and  UNIX  operating  system. 
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In  the  same  direetory  as  Java™  2,  Java  must  be  installed  on  the  system 
being  used.  The  Java  3D™  API  is  a  set  of  elasses  for  writing  3D  graphies  applieations 
and  applets.  All  of  the  MetApps  prototype  stand-alone  applieations  use  version  1.1.x  or 
1.2.1  of  Java  3D™.  For  Windows  and  Solaris  (SPARC)  one  ean  download  a  1.2.1 
version  from  Sun  Mierosystems.  Java  3D™  on  Solaris  requires  OpenGL  while  on 
Mierosoft  Windows  systems  Java  3D™  requires  OpenGL  or  DireetX.  OpenGL  is  a 
software  interfaee  to  graphies  hardware  (Woo  et  ah,  1999:2)  used  by  many  different 
operating  systems  while  DireetX  provides  a  standard  graphics  development  platform  for 
Microsoft  Windows-based  computers  (Microsoft,  2001).  OpenGL  is  standard  on  most 
computer  systems,  but  if  not,  can  be  obtained  through  the  OpenGL  Internet  site  (SGI, 
2001).  DirectX  software  for  Windows  systems  is  available  through  Microsoft. 

Unidata  has  tested  the  MetApps  stand-alone  prototypes  mainly  on  the  Microsoft 
Windows,  Sun  Solaris,  and  Linux  platforms.  As  part  of  the  background  research  for  this 
thesis,  a  number  of  the  MetApps  stand-alone  applications  were  run  using  Solaris  version 
2.8  (sometimes  referred  to  as  Solaris  8)  and  Microsoft  Windows  versions  Millennium, 
2000,  and  XP.  Unidata,  as  far  as  hardware,  recommends  that  in  addition  to  an  operating 
system  that  supports  Java^'^  and  Java  3D™,  the  system  have  a  minimum  of  128  MB  of 
random  access  memory  (RAM)  available.  Table  3  shows  a  summary  of  the  experimental 
hardware  environment. 

Preliminary  experimentation  with  MetApps  and  VisAD  (which  forms  a  critical 
part  of  MetApps)  indicates  that  this  recommendation  is  unrealistic.  Some  of  the 
meteorological  model  datasets  involved  with  this  research  can  be  quite  large  and  will 
quickly  overwhelm  most  Windows  systems.  Unidata  also  states  that  a  video  card  that 
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Table  3,  Experimental  Hardware  Environment 


Hardware  Environment 

Windows  PC 

UNIX  Workstation 

Operating  System 

Microsoft  Windows  XP, 

Home  Edition  (Build  2600) 

Sun  Microsystems,  Solaris  2.8 

Processor 

Pentium  Ill-mobile,  1  GHz 

Sparc  Ultra  1 0,  440  MHz 

Memory 

512  MB 

1  GB 

Video  Hardware 

Supports  DirectX  hardware 
acceleration 

Supports  OpenGL  hardware 
acceleration 

supports  hardware  acceleration  under  OpenGL  is  recommended  but  not  necessary  for  3D 
applications.  Preliminary  research  for  this  thesis  would  indicate  that  indeed  this 
recommendation  is  also  not  realistic.  Running  the  MetApps  Gridded  Data  Viewer 
application  on  a  hardware  platform  with  a  non-OpenGL  video  card  made  the  3D  features 
unusable.  Lastly,  Unidata  recommends  processor  speeds  of  200Mhz  on  either  a  Sun 
Sparc  or  Intel  platform  as  a  minimum.  (UCAR,  2000) 

3.6  Data  Requirements  and  Handling 

In  order  to  test  the  two  experimental  approaches  to  building  an  application 
described  above,  real  meteorological  model  data  is  required.  The  initial  approach  in  this 
research  was  to  use  MM5  model  data  provided  by  the  Air  Force  Weather  Agency.  This 
dataset  is  virtually  identical  to  the  one  used  by  the  Air  Force  Weather  Agency 
Technology  Exploitation  Branch  to  produce  the  model  products  available  through 
IGrADS.  The  format  of  this  data  is  Grid  in  Binary  (GRIB)  and  can  be  read  by  GrADS 
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using  a  ctl  file.  GRIB  is  the  gridded  data  standard  used  by  the  World  Meteorologieal 
Organization.  NCEP  (the  National  Centers  for  Environmental  Prediction)  uses  GRIB  for 
all  the  files  produced  by  their  analyses.  MetApps  was  not  designed,  however,  to  read 
GRIB  data.  Instead,  netCDE  is  the  favored  data  format.  Thus,  several  attempts  were 
made  during  the  early  course  of  this  thesis  to  convert  the  available  MM5  meteorological 
model  data  from  GRIB  to  netCDE.  These  attempts  proved  less  than  satisfactory.  In 
order  to  convert  GRIB  data  to  netCDE  format,  a  UNIX-based  system  was  used.  The 
reason  for  this  is  that  data  conversion  software  that  will  run  on  Microsoft  Windows-based 
personal  computers  is  extremely  limited,  but  available.  Most  standard  meteorological 
data  conversion  software  was  designed  to  run  exclusively  on  UNIX  platforms.  In 
addition,  the  software  configuration  proved  quite  large  and  complex.  This  approach  to 
handling  the  model  data  was  later  abandoned  for  several  reasons.  The  fact  that  a  UNIX 
platform  was  going  to  be  used  to  convert  data  made  this  endeavor  not  platform- 
independent  and  therefore  did  not  fit  in  with  the  goals  of  this  thesis.  Second,  most  end- 
users  do  not  have  the  facilities  at  their  disposal  to  perform  the  data  conversions  required 
to  view  a  particular  model  data  format.  Most  end-users  use  Windows  PCs  and  thus  data 
conversion  operations  are  not  practical  due  to  the  time  and  system  requirements.  It  was 
therefore  determined  that  the  most  practical  way  to  provide  the  necessary  meteorological 
model  data  files  to  end-users  is  to  convert  the  GRIB  data  into  the  proper  format  on  a 
centrally  located  workstation  and  then  serve  the  properly  formatted  data  to  users  via  an 
Abstract  Data  Distribution  Environment  (ADDE)  server.  This  “proper”  format  is 
network  Common  Data  form  (netCDE). 
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What  exactly  is  netCDF?  Unidata’s  netCDF  is  an  interface  for  array-oriented  data 
access  and  a  library  that  provides  an  implementation  of  the  interface.  The  netCDF  library 
also  defines  a  machine-independent  format  for  representing  scientific  data.  Together,  the 
interface,  library,  and  format  support  the  creation,  access,  and  sharing  of  scientific  data. 
The  freely  available  software  implements  the  data  model  in  several  computer- 
programming  languages  (Rew  et  ah,  1997).  NetCDF  is  used  in  thirty  countries  and 
several  groups  have  adopted  netCDF  as  a  standard  way  to  represent  some  forms  of 
scientific  data.  The  netCDF-2  Java™  Library  is  a  Java^'’^  interface  to  netCDF  data  files 
and  is  built  on  the  MultiArray  package.  Also  included  in  this  library  is  a  netCDF 
interface  to  files  that  are  accessed  through  a  Distributed  Oceanographic  Data  System 
(DODS)  server.  The  library  is  composed  of  three  packages,  ucar.nc2,  ucar.nc2.dods,  and 
ucar.ma2.  The  implementation  uses  some  of  the  code  from  the  earlier  NetCDF  Java™ 
library,  but  the  API  is  distinct  and  logically  unconnected  to  the  original.  The  netCDF 
library  is  completely  incorporated  into  the  MetApps  library  (metapps.jar). 

The  two  experimental  applications  developed  for  this  thesis  were  tested  on 
netCDF  data  files  obtained  from  Uni  data  and  data  files  stored  locally  at  the  Air  Force 
Institute  of  Technology.  These  included  GRIB  (in  netCDF  format),  surface,  and  upper- 
air  data.  The  GRIB  files  consisted  of  model  output  grids  of  various  commonly  used 
meteorological  models,  but  not  MM5. 

There  is  no  conversion  of  MM5  model  output  to  netCDF  format  involved  in  the 
research  for  this  thesis.  The  logistical  and  software  configuration  questions  involved  in 
conversion  of  the  Air  Force  Weather  Agency’s  MM5  model  output  into  netCDF  format 
falls  outside  the  scope  of  this  thesis.  Also,  no  attempt  was  made  to  deal  with  database 
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requirements.  Database  issues  will  need  to  be  addressed  at  a  later  time  should  there  be  a 
desire  to  adopt  the  use  of  MetApps  in  the  operational  military  aviation  weather 
eommunity.  Work  has,  however,  been  done  elsewhere  to  address  the  database  issues 
involved  with  the  development  of  pure  Java  eomponent-based  meteorologieal 
applieations.  The  4DWX  projeet  has  attempted  to  taekle  the  Java™  database  ehallenge. 
This  effort  met  with  some  sueeess  (NCAR,  2000). 
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4.  Results 


4.1  Overview 

The  results  obtained  from  construction  of  the  two  experimental  applications 
described  in  Chapter  3  are  discussed  in  this  chapter.  The  two  experimental  applications 
are  compared  against  the  criteria  listed  in  Chapter  3  and  summarized  here:  The  first  of 
these  criteria  is  that  the  software  solution  developed  using  the  existing  components  be 
platform-independent.  Second,  the  software  solution  must  not  be  restricted  to  obtaining 
data  from  a  single  source,  as  has  been  the  case  in  the  past.  Third,  the  solution  must  be 
robust.  “Normal”-sized  model  data  files  should  be  able  to  be  run  on  a  component-based 
application  without  putting  undue  strain  on  a  mid-level  system.  Fifth,  the  software 
solution  should  be  user-friendly.  Last,  the  selected  software  solution  must  be  an 
improvement  over  current  visualization  applications  used  in  the  operational  aviation 
weather  environment.  The  results  ended  up  being  both  positive  and  negative.  The  type 
of  component-based  approach  used  separates  the  description  of  the  results  below.  Some 
of  the  results  inevitably  overlapped  but  some,  such  as  those  related  to  deprecation  issues 
are  applicable  only  to  the  second  experimental  approach  that  used  the  MetApps 
component  library. 

4.2  Application  Design  Approach  1 

In  this  first  experimental  application  design,  an  application  was  constructed  using 
the  Borland  JBuilder  5  development  environment.  This  application  was  designed  to  act 
as  a  launch  pad  for  the  three  MetApps  prototype  stand-alone  applications  currently 
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included  as  part  of  MetApps.  In  other  words,  the  compiled  bytecode  in  the  GDV.jar, 
ImageViewer.jar,  and  Inter activeSounding.jar  took  preeedence  over  the  classes  contained 
in  the  MetApps  component  library  at  the  time  of  applieation  eompilation.  Figure  10 
shows  is  a  screenshot  of  the  experimental  application  constructed  using  the  first 
experimental  approach. 


^xi 


:!io:  01  O1/131S0O 
rao7aioiiuiooo 
7UO3-01-O1Mip16DO 

{3002  01  01/171900 
1/002  01  01/181900 
I2003-01-01/10I900 
I2002-01-01/30  1500 
i3002-0l-01/31  1900 


rot  IMP 

Cnddod  Dot*  Vl«w*r|  Imog*  Viowor  trrtoraetlv*  Sounding  | 

Tho  intordctivo  Scurving  stond-atooo  appfccaoon  alcws  usors 
to  dispttfy  griddiK]  duUi  from  local  and  ronxxo  daUiMts 

Click  her*  to  liunch  Intoractivo  Sounding  Application 


flit  CM  8IM*T  wind  SItir  Modogrtph _ 


PlPtilKt 

nPt 

0«Op<l»fflM  MHuM 

90 

C*i' 

PowntM  TirnpirakK* 

C«l 

9«f  Cqg»rPof  T*«np' 
safijiakon  uotnp  fratia 

C«l 

_ 

Ttfnppfaiuft 

OuwROM 

UBorig-KMo 

□  C«l 
C«i 

=-r; 

^natn  Mpm  ytow  Connoip*  looH  l^ 

■E-  .JSlxl 

1 

tf»g 

v, 

o*g 

l 

nPa 

‘’llS  4 

[ 

C«l 

IWB  -w  \  ^ 

! — 

an 


fyutm  fipdont 

RtmoMOMt|LMal03tt) 

imjgt  lotdii  ftom  oioup  RTHmo^s 


|OOE&  (-att  Moiti  Amtnct  n 
AvMMM  Timte 


Otpitylmtott  I 


Figure  10,  Experimental  Application  Screenshot,  This  screenshot  shows  the 
experimental  control  panel  (iMetAppsl)  with  the  three  MetApps  stand-alone 
prototype  applications  it  is  intended  to  launch. 


The  results  aehieved  by  taking  the  first  experimental  approach  to  building  an 
application  using  the  MetApps  components  were  mixed.  A  positive  result  of  the 
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experimental  approaeh  is  that  the  applieation  ereated  is  eompletely  platform-independent, 
as  expeeted  sinee  pure  Java™  was  used.  On  the  whole,  the  behavior  of  the  applieation 
running  on  the  Windows  PC  is  virtually  identieal  to  the  applieation  running  on  a  UNIX 
workstation.  Thus,  the  requirement  of  platform  independenee  appears  to  be  eompletely 
met  using  MetApps.  A  seeond  requirement,  whieh  initially  appears  to  be  met,  is  that  the 
software  solution  not  be  restrieted  to  obtaining  data  from  a  single  souree.  The  Gridded 
Data  Viewer  (GDV)  and  the  Interaetive  Sounding  Applieation  behave  reliably.  Both 
were  able  to  suoeessfully  load  loeal  and  remote  Abstraet  Data  Distribution  Environment 
(ADDE)  server  data  sets  and  allowed  unrestrieted  interaetion  with  the  data.  On  the  other 
hand  there  were  signifieant  problems  with  the  Image  Viewer.  Aeeording  to  Unidata  the 
Image  Viewer  ean  be  used  to  read  both  remote  and  loeal  imagery.  During  the 
experimentation  phase  of  this  thesis  researeh,  the  image  viewer  was  used  to  depiet  both 
United  States  GOES  and  European  Meteosat  satellite  imagery.  When  loading  remote 
imagery  via  an  ADDE  server,  no  problems  were  eneountered.  However,  when  loading 
loeal  imagery,  invariably  problems  were  eneountered.  Within  seeonds  of  attempting  to 
load  a  MelDAS  AREA  satellite  image  file  the  Image  Viewer  applieation  would  generate 
a  Java^'^  out-of-memory  exeeption.  Using  a  memory  monitor  it  was  determined  that  the 
applieation  would  effeetively  use  over  300  MB  of  memory  upon  eaeh  attempt  to  load  a 
loeal  AREA  file.  Identieal  results  were  aehieved  with  the  Image  Viewer  when  it  was  not 
part  of  the  experimental  indieation.  This,  of  eourse,  effeetively  renders  the  Image  Viewer 
useless  as  a  tool  for  viewing  imagery  loeally.  However,  the  viewer  still  meets  the 
multiple  data  souree  requirement. 
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The  third  requirement  was  that  the  solution  must  be  robust  and  that  normal-sized 
model  data  files  should  be  able  to  be  run  on  a  eomponent-based  applieation  without 
putting  undue  strain  on  a  mid- level  Windows  PC  or  an  average  UNIX  workstation.  This 
requirement  was  not  met.  Running  any  of  the  separate  MetApps  prototype  stand-alone 
applieations  by  themselves  already  pushed  the  hardware  limits  of  the  experimental 
environment.  When  two  or  more  applieations  ran  simultaneously,  resourees  beeame 
extremely  strained  and  eaused  memory  errors  even  on  systems  with  512  and  1024  MB  of 
RAM.  Another  problem  with  the  stand-alone  prototypes  is  that  they  have  a  tendeney  to 
throw  uneaught  VisAD  and  Java^'^  remote  method  invoeation  exeeptions.  A  Java™ 
exeeption  is  an  abnormal  eondition  that  arises  in  a  eode  sequenee  at  runtime.  The 
exeeptions  that  are  thrown  appear  to  be  part  of  the  normal  functioning  of  the  MetApps 
prototypes,  but  they  can  prove  awkward  when  developing  an  application  and  should  be 
dealt  with  appropriately.  The  exceptions  were  dealt  with  by  some  exception  handling 
code  in  the  experimental  applications  that  were  constructed  for  this  thesis.  The  presence 
of  these  undocumented  exceptions  brings  attention  to  how  experimental  MetApps  still  is. 

The  fourth  requirement  was  that  the  solution  must  be  extensible  or  upgradeable. 
An  application  built  on  the  MetApps  library  should  be  relatively  easy  to  adapt.  Through 
experimentation  this  requirement  was  met.  An  awkward  side  effect  initially  with  the  first 
experimental  application  was  that  every  time  a  subcomponent  was  closed  the  entire 
application  would  terminate.  This  appeared  to  be  a  result  of  the  way  the  MetApps 
prototype  stand-alone  prototypes  were  coded.  To  demonstrate  how  simple  it  was  to  adapt 
the  code  to  deal  with  this  problem,  a  relatively  crude  form  of  component  engineering  was 
applied  to  the  problem.  An  updated  component  (or  actually  a  Java™  class)  was 
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constructed  to  replace  the  eomponent  causing  the  problem.  The  inter  Sounding.]  ava  class 
replaced  the  SoundingApplication.java  elass  in  the  Interactive  Sounding  Application, 
which  was  causing  the  undesirable  behavior.  This  successful  alteration  of  the  code  shows 
how  extensible  and  upgradeable  MetApps  actually  can  be.  Hence,  the  upgradeability 
requirement  is  met,  but  some  recoding  may  be  required  if  changes  are  made  to  the 
application. 

The  fifth  requirement,  dealing  with  user-friendliness,  was  met  by  the  construction 
of  a  graphical  user  interface  (GUI)  using  the  Borland  JBuilder  environment.  This  task 
was  rather  straightforward  and  took  advantage  of  the  swing  widgets  that  eome  standard 
with  the  Java^'^  2  SDK.  The  end  result  was  a  utilitarian  interface  that  is  simple, 
functional,  and  eliminated  the  need  for  a  command  line. 

The  final  requirement  was  that  the  MetApps  solution  must  be  an  improvement 
over  current  visualization  applications  used  in  the  operational  aviation  weather 
environment.  Regrettably  this  requirement  could  not  be  met.  Although  the  experimental 
MetApps-based  application  offers  some  improved  functionality  as  far  as  interaction  with 
data  sets  it  cannot  reproduce  the  produets  that  are  eurrently  being  generated  using 
GrADS.  One  of  the  most  popular  aviation  weather  products  is  the  meteorogram.  There 
are  plans  to  incorporate  functionality  in  MetApps  that  will  support  meteorogram 
generation  and  time-series  in  general;  however,  the  current  version  of  MetApps  does  not 
support  these  capabilities.  Hence,  MetApps  does  not  meet  this  requirement.  In  addition, 
the  experimental  applications  constructed  for  this  thesis  were  very  large.  Construction  of 
Java™  application  archives  resulted  in  a  28.1  MB  Java™  archive  (JAR)  file  for  the  first 
approach  and  16.6  MB  size  for  the  second  experimental  approach.  These  JARs  only 
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included  the  so-called  required  classes.  If  there  were  an  attempt  to  turn  these  applieations 
into  web-applieations  or  applets,  the  result  would  be  a  monstrosity  that  would  take  up  an 
inordinate  amount  of  bandwidth.  This  largeness  is  not  a  configuration  problem  but  rather 
the  result  of  the  large  number  of  libraries  that  MetApps  requires  to  function  properly.  To 
eurrently  obtain  products  via  JAAWIN  all  one  needs  is  a  Java™-enabled  browser  and  a 
modem. 

A  partieularly  disturbing  result  of  attempting  the  incorporation  of  the  MetApps 
prototypes  in  an  experimental  applieation  was  related  to  the  Gridded  Data  Viewer 
(GDV).  There  appear  to  be  a  number  of  conflicts  between  the  GDV  and  the  Swing 
widgets  used  to  construct  the  experimental  applieation  user  interfaees.  These  eonflicts 
persisted  throughout  six  months  of  successive  iterations  of  the  experimental  applications. 
Finally,  a  decision  was  made  to  run  the  GDV  in  a  completely  separate  process,  bypassing 
the  conflict  entirely.  Henee,  the  GDV  was  no  longer  part  of  a  single  applieation. 

4.3  Application  Design  Approaeh  2 

The  second  application  design  approach  yielded  similar  results  to  those  found 
with  the  first.  In  this  approaeh  however  the  experimental  MetApps  application  was  built 
from  source  eode  rather  than  the  prototype  applications.  This  added  some  additional 
interesting  angles  to  the  results. 

The  results  achieved  by  taking  the  second  experimental  approach  to  building  an 
application  using  the  MetApps  library  were  mixed.  As  with  the  first  approaeh,  the 
applieation  ereated  is  completely  platform-independent.  Behavior  of  the  applieation 
running  on  the  Windows  PC  is  identical  to  the  one  running  on  a  UNIX  workstation.  The 
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requirement  of  platform  independenee  appears  to  be  eompletely  met.  The  seeond 
requirement  is  that  the  software  solution  not  be  restrieted  to  obtaining  data  from  a  single 
souree.  The  Interaetive  Sounding  Applieation  behaved  reliably  as  with  the  first  approaeh. 
On  the  other  hand  there  were  signifieant  problems  with  the  Image  Viewer.  Two  of  the 
four  elasses  required  to  eonstruet  the  Image  Viewer  Applieation  were  eompletely  omitted 
from  the  MetApps  souree  eode  libraries.  Henee,  the  eapabilities  of  the  Image  Viewer 
eould  not  be  replieated  without  inelusion  of  the  Image  Viewer  prototype  stand-alone 
applieation  JAR  files.  This  however  would  have  made  the  seeond  experimental  approaeh 
identieal  to  the  first,  making  any  attempt  at  a  seeond,  different,  approaeh  irrelevant.  It 
ean  be  eoneluded  therefore  that  the  image  viewer  ean  aetually  not  be  generated  from  the 
MetApps  souree  eode.  Curiously,  there  exists  no  doeumentation  as  to  why  these  elasses 
were  omitted  from  the  souree  eode.  Sueh  an  omission  ean  be  attributed  to  poor 
doeumentation  or  software  engineering  praetiees  (eonfiguration  management  in 
partieular). 

The  third  requirement  was  that  the  solution  be  robust  and  that  normal-sized  model 
data  fdes  should  be  able  to  be  run  on  a  eomponent-based  applieation  without  putting 
undue  strain  on  a  mid-level  system.  This  requirement  was  not  met  and  results  were 
almost  identieal  to  those  experieneed  with  the  first  approaeh.  As  with  the  first 
experimental  approaeh  the  eomponents  throw  uneaught  VisAD  and  Java^"^  remote 
method  invoeation  exeeptions.  The  exeeptions  were  dealt  with  in  the  same  way  as  with 
the  first  approaeh,  by  exeeption  handling  eode.  The  presenee  of  undoeumented 
exeeptions  in  the  souree  eode  is  further  indieation  of  the  experimental  nature  of  MetApps. 
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The  fourth  and  fifth  requirements  dealing  with  extensibility/upgradeability  and 
user-friendliness  appear  to  be  mostly  met.  The  ability  to  eustomize  an  applieation  using 
this  approach  is  much  greater  than  with  the  first.  A  developer  is  not  restricted  here  by 
what  is  contained  in  the  JAR  of  a  particular  MetApps  application.  The  developer  can 
pick  and  choose  the  classes  from  the  component  library  necessary  to  meet  a  particular 
requirement.  The  application  constructed  using  this  second  approach  in  this  thesis  is  very 
similar  in  its  capabilities  to  the  application  constructed  using  the  first.  The  sixth 
requirement  is  not  satisfied  since  the  application  constructed  did  not  appear  to  be  a 
significant  improvement  over  current  applications.  Due  to  time  constraints  and  the  poor 
state  of  the  MetApps  documentation,  extensive  customization  of  an  application  was  not 
attempted  as  part  of  this  research.  Whether  or  not  an  application  can  be  built  that  is  an 
improvement  over  current  visualization  applications  is  dependent  on  a  number  of  factors; 
among  these  are  the  skill  and  patience  of  the  individual  software  developer. 

The  most  troubling  result  of  taking  this  second  approach  to  building  an 
experimental  MetApps  application  is  related  to  deprecation.  Deprecated  methods  all 
produce  warnings  that  let  a  developer  know  that  he  or  she  is  advised  to  use  the  newer 
method.  Deprecation  allows  an  industry  to  gradually  remove  parts  of  software  that  are 
intended  to  be  phased-out  but  which  cannot  be  phased-out  immediately  because  too  many 
programs  depend  on  the  retired  parts.  The  deprecation  problem  stems  from  the  fact  that 
the  prototype  applications  and  components  in  MetApps  were  developed  sequentially  over 
a  period  of  several  years.  As  one  part  of  MetApps  was  completed  it  was  added  to  the 
MetApps  library  and  development  was  begun  on  the  next  application  or  component. 
Deprecation  is  particularly  bad  with  the  VisAD  packages  upon  which  MetApps  heavily 
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depends.  The  VisAD  projeet  and  library  has  been  under  eontinuous  development 
eompletely  apart  and  separate  from  MetApps  and  is  still  undergoing  ehanges.  The  result 
of  this  parallel  development  has  been  that  some  elasses  upon  whieh  MetApps  depends  no 
longer  exist  in  the  most  reeent  version  of  the  VisAD  library.  For  instanee,  the  Interaetive 
Sounding  Application  was  completed  around  July  of  2000.  If  one  were  to  compile  and 
run  this  application  and  then  attempt  to  load  an  upper-air  sounding,  one  would  not  be  able 
to  render  a  3D  hodograph.  The  reason  for  this  is  that  the  required  classes  to  perform  this 
action  have  been  removed  from  VisAD.  In  fact,  a  total  of  five  classes,  two  interfaces, 
two  exceptions,  twenty-six  constructors,  and  well  over  fifty  methods  have  been 
deprecated  in  VisAD  since  the  project’s  inception.  This  deprecation  problem  does  not 
manifest  itself  in  the  first  experimental  approach  of  this  thesis.  The  reason  for  this  is  that 
the  version  of  VisAD  that  was  current  at  the  time  the  Interactive  Sounding  Application 
was  completed,  is  wholly  included  in  the  application  JAR. 

On  a  more  positive  note,  the  size  of  the  experimental  application  resulting  from 
building  from  source  code  is  smaller  than  that  in  the  first  approach  used.  However,  at 
16.6  MB  even  this  improvement  in  the  size  of  the  application  does  not  make  it  very 
Internet- friendly. 

4.4  Summary  of  Results 

A  summary  of  the  experimental  results  is  provided  in  Table  3.  The  question  of 
whether  or  not  the  requirements  were  met  is  answered  with  YES,  NO,  or  MAYBE. 

The  Java™  source  code  for  the  experimental  applications  constructed  as  part  of 
this  thesis  is  included  in  Appendix  C. 
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Table  4,  Summary  of  Experimental  Results 


Requirement 

Design  Approach  1 

Design  Approach  2 

1 .  Platform  Independent 

YES 

YES 

2.  Multiple  Data  Sourees 

YES 

YES 

3.  Normal  Behavior 

NO 

NO 

4.  Upgradeable 

YES 

YES 

5.  User-Friendly 

YES 

YES 

6.  Improvement  over  Current 
Capabilities 

NO 

MAYBE 
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5.  Conclusions  and  Recommendations 


Work  centers  today  that  provide  meteorologieal  imagery  produets  to  military 
users  depend  on  state-of-the-art  eomputing  systems.  These  state-of-the-art  systems  are 
aetually  large  monolithie,  platform-dependent  applieations.  MelDAS,  GrADS,  and 
Vis5D  fall  into  this  eategory  even  though  there  are  ways  to  port  them  to  other  platforms. 
Some  progress  has  been  made  in  faetoring  out  eommon  eode  in  these  systems  into 
eommon  libraries  or  APIs  (Applieation  Programmer's  Interfaees)  sueh  asVis5D.  With 
eaeh  sueeessive  software  release,  a  little  more  of  the  eode  is  faetored-out  into  the  shared 
libraries.  However,  beeause  of  other  issues  sueh  as  baekward  eompatibility  and  legaey 
systems  support,  these  attempts  at  modularization  have  been  mostly  thwarted.  The  end 
result  of  this  proeess  is  some  very  large  (one  gigabyte  sized)  systems  sueh  as  MelDAS. 
Seientists  using  Fortran  did  the  pioneering  work  in  these  meteorologieal  systems.  Their 
goal  was  to  implement  mathematieal  algorithms  as  effieiently  as  possible.  The  laek  of 
proper  software-engineering  praetiees  in  the  development  of  these  systems  is  evident. 
This  limits  the  flexibility  and  reusability  of  these  systems. 

Sinee  the  mid  90 ’s  there  has  been  a  proliferation  of  stand-alone  workstations  and 
Mierosoft  Windows  PCs,  whieh  in  many  oases  have  better  graphios  oapabilities  than 
large  dedioated  meteorologieal  visualization  systems.  A  few  “hero”  meteorologist- 
programmers  took  on  the  ohallenge  of  porting  parts  of  the  large  meteorologieal  systems 
to  the  new  stand-alone  hardware  and  Internet  oommunity.  These  “heroes”  in  many  oases 
have  a  muoh  better  grasp  of  good  software  development  praetiees  than  the  original 
oreators  of  the  systems  they  are  taokling.  An  example  of  sueh  an  adaptation  oan  be  seen 
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at  the  Air  Force  Weather  Agency  Technology  Exploitation  Branch.  They  have  achieved 
the  successful  combination  of  GrADS  with  a  Java™  interface  to  provide  user-customized 
aviation  weather  products  to  customers  on-demand.  Even  these  valiant  efforts,  though, 
will  not  prevent  the  eventual  demise  of  systems  such  as  GrADS.  Eventually,  dependence 
on  third  parties,  legal  issues  with  the  same,  and  the  complexity  and  size  of  the  systems 
makes  maintenance  and  the  addition  of  new  features  extremely  difficult. 

Into  this  world  of  monolithic  platform-dependent  systems  entered  the  concept  of 
component-based  software  engineering  (CBSE).  Unidata  extended  the  netCDE  model  to 
Java™  and  projects  such  as  VisAD  implemented  the  concepts  found  in  CBSE.  These 
were  followed-up  by  projects  such  as  MetApps  and  4DWX  VMET  that  have  exploited 
the  components  found  in  these  libraries  and  in  turn  built  more  complex  components. 
Although  brave  and  innovative,  these  forays  into  the  cutting  edge  of  geophysical 
visualization  application  development  are  still  largely  experimental. 

There  are  important  factors  that  must  be  considered  before  adopting  the  use  of 
software  components  and  a  component-based  software  solution.  Although  the  quality 
improvement  of  products  built  using  CBSE  is  well  documented  (Pressman,  2001)  there 
are  drawbacks  to  the  approach.  The  development  of  component-based  software  is  harder 
than  traditional  software  development.  In  addition,  there  are  the  up-front  costs  involved 
in  retraining  personnel  in  the  new  software  development  approach.  Of  course,  in  the  case 
of  the  Air  Eorce  Weather  Agency  Technology  Exploitation  Branch,  development  of  new 
components  would  be  minimal.  Instead,  emphasis  would  be  placed  on  re-use  of  existing 
components  in  an  effort  to  minimize  costs  related  to  software  development.  The  problem 
that  would  be  encountered  here  is  that  in  order  to  use  software  components  effectively,  a 


55 


developer  must  have  extensive  knowledge  of  the  eomponent  library  in  question.  This 
problem  was  eneountered  over  the  eourse  of  this  thesis  researeh.  Mueh  time  was  spent 
simply  analyzing  the  elass  strueture  of  the  MetApps  and  assoeiated  libraries  rather  than 
eonstrueting  the  aetual  experimental  applieations.  Component-based  development  using 
poorly  designed  or  doeumented  software  eomponents,  such  as  those  in  MetApps,  is 
therefore  filled  with  pitfalls.  With  the  current  state  of  component-based  development 
technologies  and  the  limitations  of  components,  component-based  development  by 
personnel  with  limited  computing  expertise  should  only  be  attempted  with  great  caution. 

The  prototype  applications  built  with  MetApps  show  that  the  experimental 
designs  used  in  this  research  will  work.  From  the  progress  that  has  been  made  thus  far,  it 
can  be  seen  that  some  day  Java™  applications  built  from  components  such  as  those  found 
in  the  MetApps  library  may  be  part  of  the  ideal  operational  weather  system.  That  day, 
regrettably,  is  not  today.  Although  prototype  applications  based  on  a  component  library, 
in  this  case  MetApps,  were  successfully  constructed  over  the  course  of  this  thesis 
research,  they  are  by  no  means  of  operational  caliber.  As  can  be  seen  from  the  results 
discussed  in  Chapter  4,  Unidata  MetApps  is  still  too  experimental  to  be  used  in  an 
operational  environment.  It  is  yet  too  unpredictable  and  unstable,  and  lacks  the 
robustness  required  of  an  operational  system.  Systems  such  as  GrADS,  even  though  not 
ideal,  have  the  stability  and  predictability  that  are  required  of  operational  systems.  The 
current  iteration  of  MetApps  is  best  suited  for  the  academic  research  environment.  One 
could,  however,  reasonably  conclude  that  at  the  pace  at  which  progress  is  being  made 
with  the  development  of  MetApps,  a  more  stable  and  non-experimental  version  should 
become  available  within  the  next  two  years.  Although  it  is  recommended  that  close 
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attention  should  be  paid  as  to  further  developments  in  MetApps,  MetApps  should  not  be 
included  in  any  operational  aviation  weather  products  generation  software  system  at  this 
time. 

Over  the  course  of  this  research,  Java™  component  libraries  other  than  MetApps 
were  encountered.  One  that  shows  great  promise  is  the  Visualization  for  Algorithm 
Development  (VisAD)  library.  The  research  community  has  successfully  used  VisAD. 
Future  research  might  include  the  development  and  testing  of  customized  military 
aviation  product  generation  software  solutions  built  entirely  from  VisAD  Java™ 
components.  In  addition,  future  research  should  look  more  closely  into  possible  ways  of 
dealing  with  the  numerous  database  issues  involved  in  using  Java™  to  manipulate  and 
display  large  meteorological  model  data  sets. 
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2D 

3D 

4DWX 

5D 

ADDE 

AFWA 

AFWIN 

API 

ATEC 

CBSE 

COFA 

COTS 

DAO 

DNXT 

DODS 

GB 

GDV 

GHz 

GOES 

GrADS 

GRIB 


Two-dimensional 
Three-dimensional 
Four-dimensional  Weather  System 
F  ive-dimensional 

Abstract  Data  Distribution  Environment 
Air  Force  Weather  Agency 
Air  Force  Weather  Information  Network 
Application  Programming  Interface 
Army  Test  and  Evaluation  Command 
Component-Based  Software  Engineering 
Center  for  Ocean-Fand-Atmosphere  Studies 
Commercial  Off-the-shelf  Software 
Data  Assimilation  Office 
AFWA  Technology  Exploitation  Branch 
Distributed  Oceanographic  Data  System 
Gigabyte 

Gridded  Data  Viewer 
Gigahertz 

Geosynchronous  Operational  Environmental  Satellite 
Grid  Analysis  and  Display  System 
GRid  in  Binary 
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ICAO 


International  Civil  Aviation  Organization 
IMaST  Interactive  Meteorogram  and  Skew-T 

JAAWIN  Joint  Air  Force  and  Army  Weather  Information  Network 
JAR  Java™  Archive 

km  kilometer 

MB  Megabyte 

MHz  Megahertz 

MetApps  Meteorological  Applications 

MGWDS  Mesoscale  Gridded  Window  Display  System 

MM5  Mesoscale  Model  5 

NCAR  National  Center  for  Atmospheric  Research 

netCDF  network  Common  Data  Form 

PC  Personal  Computer 

RWM  Relocatable  Window  Model 

SGI  Silicon  Graphics  Incorporated 

SSEC  Space  Science  and  Engineering  Center 

UCAR  University  Corporation  for  Atmospheric  Research 

UMADA  Unidata  MetApps  Discussion  Area 

VisAD  Visualization  for  Algorithm  Development 

VMET  Visual  Meteorology  Tool 


59 


Appendix  B:  Unidata  MetApps  Detailed  Analysis 


B.l  Overview 

Provided  here  is  an  in-depth  analysis  of  MetApps,  whieh  forms  the  basis  for  the 
experiments  that  are  performed  as  part  of  this  thesis.  MetApps  (Meteorological 
Applications)  is  available  both  as  a  Java^'^  library  and  as  a  number  of  stand-alone 
applications.  Without  fully  elaborating  on  what  these  two  separate  (but  related)  versions 
of  MetApps  are  composed  of,  it  would  not  be  possible  to  fully  explain  the  design 
approach  taken  in  this  thesis.  Each  of  the  MetApps  “versions,”  both  the  library  and 
applications,  has  its  merits  and  drawbacks  when  used  in  building  a  meteorological 
application  and  these  will  be  discussed  further  in  sections  of  this  document  dealing  with 
experiment  design.  What  follows  in  the  next  two  sections  is  a  breakdown  of  the 
MetApps  library  and  the  available  MetApps  stand-alone  applications. 

B.2  Design  of  MetApps  Prototype  Stand-alone  Applications 

An  application  is  a  piece  of  software  that  is  intended  to  be  used  in  a  stand-alone 
manner.  Since  the  inception  of  the  Unidata  MetApps  project  the  number,  type,  and  even 
the  names  of  stand-alone  MetApps  applications  has  remained  fluid.  Among  the  earlier 
stand-alone  applications  (during  1999)  was  the  Surface  Observation  Viewer  (SOV) 
Application.  Although  most  of  the  Java™  classes  associated  with  the  SOV  are  still 
present  some  classes  critical  to  the  proper  operation  of  this  application  have  been 
deprecated.  In  addition,  there  are  applications  currently  being  developed  through  Unidata 
such  as  the  Radar  Data  Viewer,  which  will  not  be  complete  upon  completion  of  this 
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thesis.  Upon  the  writing  of  this  thesis,  Unidata  has  available  three  MetApps  stand-alone 
applieations;  Interaetive  Sounding,  Image  Viewer,  and  Gridded  Data  Viewer. 

The  following  libraries  are  being  used  in  the  MetApps  stand-alone  prototype 
applieations:  JavaHelp™,  VisAD,  MetApps,  and  Aneillary  Data  Files.  The  JavaHelp™ 
software  library  is  a  full-featured,  platform-independent,  extensible  help  system  that 
enables  developers  and  authors  to  ineorporate  online  help  in  applets,  components, 
applications,  operating  systems,  and  devices.  It  is  being  used  as  the  interface  to  the  on¬ 
line  documentation  for  the  prototypes.  VisAD  is  a  Java^'^  class  library  for  interactive  and 
collaborative  visualization  and  analysis  of  numerical  data.  It's  data  model  and  display 
capabilities  are  being  used  in  several  of  the  prototypes.  The  MetApps  prototypes  also  use 
a  standard  library  of  classes  developed  by  Unidata  called  the  MetApps  library.  In 
addition  to  the  libraries  above,  some  ancillary  data  files  (icons,  enhancements,  map  files) 
are  used  by  the  applications  and  are  packed  together  in  the  Ancillary  Data  Files  library. 
The  libraries  are  available  from  Unidata  as  four  JAR  (Java™  Archive)  files  named  jh.jar, 
visad.jar,  metapps.jar,  and  auxdata.jar.  All  the  libraries  contain  primarily  Java™ 
bytecode  except  for  auxdata.jar,  which  contains  a  variety  of  other  formats.  It  should  be 
pointed  out  that  in  addition  to  these  libraries,  each  specific  MetApps  stand-alone 
application,  available  as  a  download  from  Unidata,  may  require  its  own  additional 
libraries  (or  JARs). 

B.2.1  Interactive  Sounding  Application 

A  MetApps  stand-alone  application  that  shows  much  promise  for  incorporation  in 
an  aviation  meteorological  software  suite  is  the  MetApps  Interactive  Sounding 
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Application.  The  Interactive  Sounding  Application  displays  RAOB  (radiosonde 
observation)-like  sounding  data  in  aerodynamic  diagrams  (e.g.  Skew  T  chart,  wind 
hodograph).  Unidata  specifies  that  this  particular  application  is  not  intended  to  become  a 
finished,  stand-alone  application  (though  that  is  not  precluded).  Rather,  its  purpose  was 
to  present  several  software  components  in  a  convenient  framework  for  the  purpose  of 
refining  the  components  (rather  than  the  application).  A  component  is  a  piece  of 
software  that  is  not  intended  to  be  used  in  a  stand-alone  manner,  but,  rather,  is  designed 
to  interact  with  other  components.  Several  interacting  components  may  form  an 
application  and  a  component  may  be  used  in  more  than  one  stand-alone  application. 
(UMADA,  2001) 

One  of  the  Sounding  Application  components,  the  wind  profile  component, 
comprises  two  sub-components:  a  3D  hodograph  and  a  wind  staff  In  the  hodograph,  the 
mean-wind  is  displayed  as  a  point.  In  the  wind  staff,  the  mean-wind  is  displayed  as  a 
white  wind-arrow.  The  Mean-wind  computation  is  only  possible  if  there  is  no  wind  data 
outside  the  domain  of  the  thermodynamic  data.  A  second  component,  the  sounding 
selector,  is  invoked  by  selecting  the  "Open  sounding..."  item  from  the  file  menu.  The 
button  labeled  Select  netCDF  Upper  Air  File  is  for  selecting  upper  air  data  in  a  netCDF 
file  that  is  available  on  a  local  drive.  Shown  in  Figure  1 1  below  is  a  screenshot  of  the 
MetApps  Interactive  Sounding  Application  showing  the  different  subcomponents  of  this 
prototype  stand-alone  application. 
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Figure  11.  Interactive  Sounding  Screenshot,  This  screenshot  of  the  MetApps 
prototype  stand-alone  Interactive  Sounding  Application  shows  its  different 

suhcomponents. 


A  more  promising  option  for  selecting  a  sounding  is  using  the  Select  ADDE 
Server  button  to  obtain  data  from  a  McIDAS  ADDE  (Abstract  Data  Distribution 
Environment)  server.  ADDE  allows  a  workstation  to  act  as  a  client,  efficiently  accessing 
data  from  multiple  McIDAS  servers.  There  are  several  advantages  to  using  ADDE  to 
access  image  data.  Eirst,  there  is  no  need  to  have  the  data  reside  on  the  local  machine. 

No  dedicated  connections  are  needed  and  access  can  be  accomplished  over  a  network 
connection  or  modem.  Data  can  be  accessed  from  within  a  military  base  for  example,  or 
from  an  ADDE  server  on  the  other  side  of  the  world.  Second,  ADDE  servers  can  be  used 
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to  access  data  in  formats  other  than  McIDAS  AREA  file  format.  Currently,  Unidata 
supports  servers  for  NIDS,  NOWRad,  and  GINI  format  in  addition  to  McIDAS  AREA 
format.  Third,  the  user  is  provided  data  redundaney  and  possibly  access  to  data  sets  that 
are  not  available  locally. 

Einally,  the  Sounding  Selection  Eist  component  appears  in  the  lower-left  comer  of 
the  main  display  of  the  Sounding  Applieation.  It  lists  the  soundings  that  have  been  added 
to  the  Interactive  Sounding  system  via  the  Sounding  Seleetor  component  and  allows 
seleetion  of  soundings  for  display,  eomputation,  or  removal.  The  Interaetive  Sounding 
Application  is  completely  self-eontained  and  requires  no  exterior  component  libraries 
other  than  those  already  mentioned  previously. 

B.2.2  Gridded  Data  Viewer  (GDV)  Application 

The  second  available  MetApps  stand-alone  application  is  the  Gridded  Data 
Viewer,  or  GDV.  The  GDV  is  a  general  tool  for  displaying  geogrids.  In  a  geogrid, 
individual  grid  elements  are  called  grid  cells.  A  geogrid  has  a  data  value  for  each  grid 
cell,  unless  the  data  is  missing.  Missing  data  is  mapped  to  the  background  color  of  the 
display.  Color  mapping  is  a  simple  display  method  where  data  intervals  are  assigned  to 
colors.  Color  mapping  allows  the  user  to  visualize  geogrids  in  a  way  that  directly  reflects 
the  data  values  of  the  geogrid.  The  2001  version  of  the  GDV  is  specialized  to  display 
model  data  output,  and  may  or  may  not  be  extended  to  display  satellite  imagery. 

Currently  the  GDV  can  read  netCDE  fdes  using  NUWG,  CSM,  COARDS,  and  GDV 
netCDE  eonventions.  (UMADA,  2001)  Eigure  12  shows  a  sereenshot  of  the  typical 
product  the  GDV  is  capable  of  producing. 
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Figure  12,  GDV  Screenshot,  This  screenshot  shows  the  gridded  Eta  meteorological 
model  850mh  24-hour  temperature  forecast  displayed  on  the  MetApps  Gridded 

Data  Viewer  (GDV), 


Current  features  of  the  GDV  include  the  ability  to  display 


-  horizontal  and  vertical  planes  (or  slices)  of  geogrids 

-  data  on  various  projective  geometries;  projections  are  parameterized  and  extensible 

-  optional  contours  of  the  data 

-  data  in  a  3D  viewer 

-  simple  looping 
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The  GDV  has  been  tested  on  Windows,  Linux,  and  Solaris  SPARC  systems  and 
ean  read  most  forms  of  netCDF  data,  although  not  all  (UMADA,  2001).  To  aetually  be 
able  to  use  the  GDV  stand-alone  applieation  some  additional  library  files  are  required 
apart  from  the  ones  previously  mentioned  that  are  required  for  all  MetApps  applieations. 
These  are  the  Distributed  Oeeanographie  Data  System  (DODS),  Frequently  Asked 
Questions  Organizer  (FAQO),  Java™  Doeument  Objeet  Model  (JDOM),  and  Xerees 
Java™  libraries. 

The  DODS  Java^'^  library  (available  as  dodsjar)  provides  support  to  the  GDV  for 
aeeessing  data  on  DODS  servers.  DODS  simplifies  aspects  of  scientific  data  networking 
by  making  local  data  accessible  to  remote  locations  regardless  of  local  storage  format. 
FAQO  is  a  tool  for  online  technical  support  groups,  who  exchange  questions,  answers, 
and  information  through  email,  Netnews,  or  other  computer-mediated  forums.  It  makes  it 
easier  for  support  group  members  to  search  archives  for  previously  asked  (and  answered) 
questions,  and  to  collaboratively  organize  and  manage  those  archives.  FAQO  uses 
advanced  information  retrieval  techniques  to  allow  natural  language  searches  for  relevant 
documents.  The  FAQO  library  (faqo.jar)  needed  by  GDV  only  consists  of  a  couple  of 
user  interface  classes.  The  JDOM  Java™  Library  contains  a  relatively  new  Java^'^  API 
for  reading,  writing,  and  manipulating  XML  from  within  Java™  code.  JDOM  brings 
with  it  the  capability  of  providing  a  full  document  view  with  random  access  but  does  not 
require  the  entire  document  to  be  in  memory.  The  JDOM  API  allows  for  future  flyweight 
implementations  that  load  information  only  when  needed  (Hunter,  2001).  Finally,  the 
Xerees  Java™  library  (xerees  jar)  brings  to  the  GDV  application  an  open-source  XML 
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parser,  which  is  available  through  the  Apache  XML  Internet  site  (Apache  Software 
Foundation,  2001). 

B.2.3  Image  Viewer  Application 

The  Image  Viewer  prototype  stand-alone  application  (shown  in  Figure  13  below) 
allows  users  to  display  image  data  from  local  and  remote  datasets.  Although  the  Image 
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Figure  13.  Image  Viewer  Screenshot.  This  screenshot  of  the  MetApps  prototype 
stand-alone  Image  Viewer  Application  shows  the  viewing  window  and  the 
remote/local  image  selection  components. 


Viewer  application  was  initially  developed  as  a  satellite  data  viewer,  the  current  viewer 
can  be  used  to  display  both  radar  and  satellite  imagery.  As  far  as  special  requirements, 
the  Image  Viewer  application  needs  only  the  standard  libraries  used  for  the  MetApps 
applications  installed  correctly.  At  the  present  time,  only  McIDAS  AREA  files  can  be 
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opened  through  the  loeal  data  aeeess  methods.  Unidata  plans  to  ineorporate  support  for 
other  image  data  formats  in  future  versions  of  the  Image  Viewer  applieation  (UMADA, 
2001).  Some  of  these  other  formats  ean  be  aceessed  through  ADDE  servers  (discussed 
above). 

The  Image  Viewer  stands  out  as  a  stand-alone  application  because  of  its 
diminutive  size.  Shown  in  Figure  14  below,  the  entire  application  consists  of  a  three 
Java™  classes  and  some  enhancements,  icons,  and  map  files.  Everything  else  in  the 
Image  Viewer  application  is  accomplished  by  importing  classes  from  the  VisAD  and 
MetApps  Java™  libraries.  The  end  result  is  a  display  application  consisting  of  a  VisAD 


Figure  14,  Image  Viewer  Class  Diagram,  This  class  diagram  of  the  Image  Viewer 
Application  shows  the  simplicity  of  this  particular  MetApps  prototype  stand-alone 

application. 
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display  window,  which  can  be  either  two  or  three-dimensional,  and  a  eouple  of  image- 
seleetion  eomponents  (or  widgets).  Size  is  a  eonsideration  when  one  plans  to  use  an 
applieation  over  the  Internet  with  limited  available  bandwidth. 

B.3  Design  of  MetApps  Library 

The  MetApps  library  eonsists  of  the  base  elasses  required  to  eonstruet  pure 
Java™  eomponents  that  are  eombined  into  applieations.  The  library  is  divided  into  a 
number  of  major  paekages.  These  are  unidata,  units,  util,  visad,  ma2,  multiararray,  nc2, 
and  netcdf.  Figure  15  shows  how  the  sub-paekages  with  the  MetApps  library  are  linked 
together.  The  dashed  arrows  show  the  dependeneies  between  paekages.  For  example, 
unidata  depends  on  util,  while  visad  and  unidata  are  interdependent.  Although  unidata  is 
presented  within  the  MetApps  library  as  a  Java™  paekage,  it  is  not  really  a  paekage  at  all 
but  rather  the  skeleton  for  organizing  a  series  of  important  sub-paekages  eaeh  of  whieh 
forms  a  eritieal  eomponent  of  the  MetApps  library.  It  is  these  eritieal  paekages,  like  the 
unidata. gridviewer  (whieh  is  the  eore  of  the  GDV  applieation)  that  are  eombined  to  build 
useful  MetApps  applieations.  The  units  paekage  provides  support  for  parsing  and 
formatting  string  unit  speeifieation,  eonverting  numerieal  values  between  eompatible 
units,  and  performing  arithmetie  on  units  (sueh  as  dividing  one  unit  by  another),  util 
simply  eonsists  of  an  interfaee  and  two  elasses  used  in  logging  server  aetivity.  The 
reader  should  note  that  the  visad  paekage  here  is  not  the  same  as  the  Vis  AD  library 
mentioned  in  Chapter  2.  A  developer  may  be  tempted  to  replaee  this  paekage  with  the 
VisAD  library,  but  this  temptation  should  be  resisted.  The  visad  paekage  provides 
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support  for  hiding  some  of  the  eomplexity  of  the  large  VisAD  paekage  that  is  required  to 
build  MetApps  applications. 
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Figure  15,  MetApps  Library  Package  Diagram,  This  figure  shows  the  principal 
near  packages  of  the  MetApps  library  and  their  interdependencies.  Note  the  large 
number  of  sub-packages  contained  in  unidata. 


The  last  four  of  the  packages  listed  above  are  actually  the  netCDF-2  library, 
which  has  been  wholly  and  permanently  incorporated  into  the  MetApps  library.  The  ma2 
package  is  actually  the  MultiArray  package.  The  MultiArray  package  is  a  stand-alone 
Java™  package  for  multidimensional  arrays  of  primitive  types.  ma2  is  the  abstraction  for 
multidimensional  arrays  of  primitives  with  data  stored  in  memory,  on  a  remote  or  local 
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input/output  device.  The  multiararray  package  provides  an  abstraction  for 
multidimensional  array  access,  some  concrete  implementations,  and  ways  to  view  a 
MultiArray  as  if  it  had  a  different  structure.  The  ucar.nc2  package  is  an  experimental 
API  for  netCDF  files,  and  the  netcdf  package  provides  an  abstraction  for  sampled 
functions  between  multidimensional  spaces. 
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Appendix  C:  Application  Source  Code 


C.l  Application! .java  Source  Code 


package  application!; 

import  javax.swing.UIManager; 
import  j  ava.awt.  * ; 


*  Title; 

*  Description: 

* 

*  Created: 

*  Company: 

*  @author 

*  @version  1.0 


iMetApps  Experimental  Application  -  Design  1 
This  is  an  experimental  application  using  design  1 .  This  experimental 
application  uses  Unidata  MetApps  prototype  stand-alone  applications 
GDV.jar,  SoundingApplication.jar,  and  ImageViewer.jar. 

December  2001 
AFIT/ENP 

Captain  Harmen  P.  Visser 


public  class  Application!  { 
boolean  packFrame  =  false; 

/**Construct  the  application*/ 
public  Application! 0  { 

Frame  1  frame  =  new  Frame  1(); 

//Validate  frames  that  have  preset  sizes 

//Pack  frames  that  have  useful  preferred  size  info,  e.g.  from  their  layout 
if  (packFrame)  { 
frame.packO; 
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} 

else  { 

frame. validate(); 

} 

//Center  the  window 

Dimension  sereenSize  =  Toolkit.getDefaultToolkit().getSoreenSize(); 

Dimension  frameSize  =  frame.getSizeQ; 
if  (frameSize.height  >  sereenSize.height)  { 
frameSize. height  =  sereenSize.height; 

} 

if  (frameSize.width  >  sereenSize.width)  { 
frameSize.width  =  sereenSize.width; 

} 

frame. setLoeation((sereenSize.width  -  frameSize.width)  /  2,  (sereenSize.height  - 
frameSize.height)  /  2); 
frame. setVisible(true); 

} 

/**Main  method*/ 

publie  statie  void  main(String[]  args)  { 
try  { 

UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName()); 

} 

oatoh(Exoeption  e)  { 
e  .prints  taekT  rae  e() ; 

} 

new  ApplieationlO; 


} 

} 
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C.2  Framel .java  Source  Code 


package  application!; 

import  j  ava.awt.  * ; 
import  j  ava.  awt.  event.  * ; 
import  j  avax . swing .  * ; 
import  j  avax  .swing. border .  * ; 
import  com.borland.jbcl. layout.*; 
import  test.*; 

import  ucar.unidata.  view. sounding.*; 
import  java.rmi.RemoteException; 
import  visad.VisADException; 
import  ucar.unidata.  gridviewer.  * ; 


*  Title: 

*  Description: 

* 

*  Created: 

*  Company: 

*  @author 

*  @version  1.0 

*/ 


IMetApps  Experimental  Application  -  Design  1 
This  is  an  experimental  application  using  design  1 .  This  experimental 
application  uses  Unidata  MetApps  prototype  stand-alone  apllications 
GDV.jar,  SoundingApplication.jar,  and  ImageViewer.jar. 

December  2001 
AEIT/ENP 

Captain  Harmen  P.  Visser 


public  class  Eramel  extends  JErame  { 

JPanel  contentPane; 

JMenuBar  jMenuBarl  =  new  JMenuBar(); 

JMenu  jMenuEile  =  new  JMenu(); 

JMenuItem  jMenuEileExit  =  new  JMenuItem(); 

JMenu  jMenuHelp  =  new  JMenu(); 

JMenuItem  jMenuHelpAbout  =  new  JMenuItem(); 
JToolBar  jToolBar  =  new  JToolBar(); 

Imagelcon  image  1; 

Imagelcon  image2; 

Imagelcon  imageS; 

JEabel  statusBar  =  new  JEabel(); 

BorderEayout  borderEayoutI  =  new  BorderEayout(); 
JTabbedPane  jTabbedPanel  =  new  JTabbedPane(); 
Border  border  I; 

JTextEield  jTextEieldl  =  new  JTextEieldQ; 
JToggleButton  jToggleButtonI  =  new  JToggleButton(); 
JPanel  jPanell  =  new  JPanel(); 
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JPanel  jPanel2  =  new  JPanel(); 

JPanel  jPaneB  =  new  JPanel(); 

JLabel  j'Label2  =  new  JLabelQ; 

JLabel  j'Labell  =  new  JLabelQ; 

JButton  jButton2  =  new  JButtonQ; 

PaneLayout  paneLayoutl  =  new  PaneLayoutQ; 

TitledB  order  titledB  order  1; 

TitledB  order  titledB  order2; 

JLabel  j'LabeB  =  new  JLabelQ; 

JLabel  j'LabeM  =  new  JLabelQ; 

JButton  j Buttons  =  new  JButtonQ; 

JButton  jButtond  =  new  JButtonQ; 

JLabel  j'LabeB  =  new  JLabelQ; 

JLabel  j'Labelb  =  new  JLabelQ; 

PaneLayout  paneLayout2  =  new  PaneLayoutQ; 

PaneLayout  paneLayoutS  =  new  PaneLayoutQ; 

/**Construot  the  frame*/ 
pub  lie  Frame  IQ  { 

enableEvents(AWTEvent.WINDOW_EVENT_MASK); 
try  { 
jblnitQ; 

} 

cateh(Exeeption  e)  { 
e  .prints  taekT  rae  eQ ; 

} 

} 

/** Component  initialization*/ 
private  void  jblnitQ  throws  Exeeption  { 

imagel  =  new  ImageIeon(applieationLErameLelass.getResouree("openEile.gif')); 
image2  =  new  ImageIeon(applieationLErameLelass.getResource("eloseEile.gif')); 
images  =  new  ImageIeon(applieationLErameLelass.getResouree("help.gif')); 

//setIeonImage(Toolkit.getDefaultToolkitQ.ereateImage(ErameLelass.getResouree("[Yo 
ur  leon]"))); 

eontentPane  =  (JPanel)  this.getContentPaneQ; 
borderl  =  BorderPaetory.ereateEineBorder(Color.gray,2); 
titledBorderl  =  new  TitledBorder(""); 
titledBorder2  =  new  TitledBorder(""); 
eontentPane. setEayout(borderEayoutl); 
this.setSize(new  Dimension(460,  26S)); 
this.setTitleC'lMetAppsl  Control  Panel"); 
statusBar.setText(" "); 

JMenuEile.setTextC'Pile"); 

JMenuEileExit.setTextC'Exit"); 
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jMenuFileExit.addActionListener(new  ActionListener()  { 
public  void  actionPerformed(ActionEvent  e)  { 
jMenuEileExit_actionPerformed(e); 

} 

}); 

jMenuHelp.setXextC'Help"); 

jMenuHelpAbout.setText("About"); 

jMenuHelpAbout.addActionListener(new  ActionListener()  { 
public  void  actionPerformed(ActionEvent  e)  { 
jMenuHelpAbout_actionPerformed(e); 

} 

}); 

jTabbedPanel.setBackground(SystemColor.inactiveCaptionText); 
jTabbedPanel.setPont(new  java.awt.Pont("Dialog",  1,  14)); 
jXabbedPane  1 .  setBorder(border  1 ); 

jXabbedPanel.setMinimumSize(new  Dimension(480,  150)); 
jXabbedPanel.setPreferredSize(new  Dimension(500,  240)); 
jXabbedPanel .addPocusEistener(new  java.awt.event.PocusAdapter()  { 

}); 

jXextP  ield  1  .setX  ext("j  X  extP  ield  1 "); 

jXogglcButton  1  .setX  ext("j  X  oggleButton  1 "); 

jPanell.setBackground(Color.lightGray); 

jPanell.setMinimumSize(new  Dimension(470,  155)); 

jPanell.setPreferredSize(new  Dimension(470,  155)); 

jPanell  .setEayout(paneEayout3); 

jPanel2.setBackground(Color.lightGray); 

jPanel2.setEayout(paneEayout2); 

contentPane.setPreferredSize(new  Dimension(500,  240)); 

jPanel3.setBackground(Color.lightGray); 

jPanel3.setEayout(paneEayoutl); 

j‘Label2.setPont(new  java.awt.Pont("Dialog",  0,  16)); 

jEabel2.setHorizontalAlignment(SwingConstants.CENXER); 

jEabel2.setHorizontalXextPosition(SwingConstants.CENXER); 

jEabel2.setXext("to  display  image  data  from  local  and  remote  datasets."); 

j'Eabell.setPont(new java.awt.Pont("Dialog",  0,  16)); 

jEabell  .setAlignmentX((float)  0.5); 

jEabell  .setAlignmentY((float)  1 .0); 

j'Eabell.setMaximumSize(new Dimension(300,  60)); 

jEabell. setMmimumSize(new  Dimension(300,  60)); 

jEabell. setPreferredSize(new  Dimension(470,  30)); 

jEabel  1 .  setX  oolXipX  ext(" "); 

jEabell. setHorizontalAlignment(SwmgConstants.CENXER); 

jEabell.setHorizontalXextPosition(SwmgConstants.CENXER); 

jEabell. setX ext("Xhe  Image  Viewer  stand-alone  applieation  allows  users"); 
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jButton2.setBackground(Color.gray); 
jButton2.setFont(new  java.awt.Font("Dialog",  1,  16)); 
jButton2.setBorder(BorderFactory.createRaisedBevelBorder()); 
jButton2.setMaximumSize(new  Dimension(419,  27)); 
jButton2.setMinimumSize(new  Dimension(419,  27)); 
jButton2.setPreferredSize(new  Dimension(419,  27)); 
jButton2.setIcon(imagel); 

jButton2.setText(" Click  here  to  launch  Image  Viewer  Application"); 
jButton2.addMouseListener(new  java.awt.event.MouseAdapter()  { 
public  void  mouseClicked(MouseEvent  e)  { 
jButton2_mouseClicked(e); 

} 

}); 

jLabel3.setText("The  Gridded  Data  Viewer  stand-alone  application  allows  users"); 
jLabel3.setHorizontalTextPosition(SwingConstants. CENTER); 
jEabel3.setHorizontalAlignment(SwingConstants. CENTER); 
jEabcB .  setT  oolTipT  ext("  "); 
j‘Eabel3.setPreferredSize(new  Dimension(470,  30)); 
jEabel3.setMinimumSize(new  Dimension(300,  60)); 
j'Eabel3.setMaximumSize(new  Dimension(300,  60)); 
jEabcB  .setAlignmentY  ((float)  1 .0); 
jEabeB.setAlignmentX((float)  0.5); 
j‘EabeB.setEont(new  java.awt.Eont("Dialog",  0,  16)); 
j‘Eabel4.setText("to  display  gridded  data  from  local  and  remote  datasets."); 
jEabel4.setHorizontalTextPosition(SwingConstants. CENTER); 
jEabel4.setHorizontalAlignment(SwingConstants. CENTER); 
j‘Eabel4.setEont(new  java.awt.Eont("Dialog",  0,  16)); 
jButton3.setText(" Click  here  to  launch  Gridded  Data  Viewer  Application"); 
jButton3.addMouseEistener(new  java.awt.event.MouseAdapter()  { 
public  void  mouseClicked(MouseEvent  e)  { 
jButton3_mouseClicked(e); 

} 

}); 

jButton3.setBorder(BorderEactory.createRaisedBevelBorder()); 
jButton3.setIcon(new  lmageIcon(ErameEclass.getResource("openEile.gif'))); 
jButton3.setEont(new  java.awt.Eont("Dialog",  1,  16)); 
jButton3.setBackground(Color.gray); 
jButton4.setBackground(Color.gray); 
jButton4.setEont(new  java.awt.Eont("Dialog",  1,  16)); 
jButton4.setBorder(BorderEactory.createRaisedBevelBorder()); 
jButton4.setlcon(new  lmagelcon(ErameEclass.getResource("openEile.gif'))); 
jButton4.setText(" Click  here  to  launch  Interactive  Sounding  Application"); 
jButton4.addMouseListener(new  java.awt.event.MouseAdapter()  { 
public  void  mouseClicked(MouseEvent  e) 

{ 
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jButton4_mouseClicked(e); 

} 

}); 

j'Label5.setFont(new  java.awt.Font("Dialog",  0,  16)); 
jLabel5.setHorizontalAlignment(SwingConstants. CENTER); 
jEabel5.setHorizontalTextPosition(SwingConstants. CENTER); 
j'Label5.setText("to  display  gridded  data  from  local  and  remote  datasets."); 
j‘Label6.setEont(new  java.awt.Eont("Dialog",  0,  16)); 
jEabel6.setAlignmentX((float)  0.5); 
jEabel6.setAlignmentY((float)  1 .0); 
jLabel6.setMaximumSize(new  Dimension(300,  60)); 
jLabel6.setMmimumSize(new  Dimension(300,  60)); 
j‘Eabel6.setPreferredSize(new  Dimension(470,  30)); 
jEabel6.setToolTipText(""); 

jLabel6.setHorizontalAlignment(SwmgConstants. CENTER); 
jLabel6.setHorizontalTextPosition(SwmgConstants. CENTER); 
jLabel6.setText("The  Interactive  Sounding  stand-alone  application  allows  users"); 
jMenuF  ile .  add(j  MenuE  ileExit) ; 
jMenuHelp .  add(jMenuHelp  About); 
jMenuBarl  .add(jMenuEile); 
jMenuBarl  .add(jMenuHelp); 
this.setJMenuBar(jMenuBar  1 ); 
contentPane.add(jToolBar,  BorderLayout.WEST); 
contentPane.add(statusBar,  BorderLayout.SOUTH); 
oontentPane.add(jTabbedPanel ,  BorderLayout.CENTER); 
jPanel3.add(jButton2,  new  PaneConstraints("jButton2",  "jButton2", 
PaneConstraints.ROOT,  0.5f)); 

jPanel3.add(jLabel2,  new  PaneConstraints("jLabel2",  "jButton2", 
PaneConstraints.TOP,  0.4407583f)); 

jPanel3.add(jLabell,  new  PaneConstraints("jLabell",  "jLabel2", 

PaneConstraints.TOP,  0.47500002f)); 
jTabbedPanel.add(jPanell,  "Gridded  Data  Viewer"); 
jPanel2.add(jEabel6,  new  PaneConstraints("jLabel6",  "jEabel6", 
PaneConstraints.ROOT,  0.5f)); 

jPanel2.add(jButton4,  new  PaneConstraints("jButton4",  "j’Label6", 
PaneConstraints.BOTTOM,  0.77669907f)); 

jPanel2.add(jLabel5,  new  PaneConstraints("jEabel5",  "jButton4", 
PaneConstraints  .TOP,0. 2863248 f)); 
jTabbedPanel.add(jPanel3,  "Image  Viewer"); 
jTabbedPanel.add(jPanel2,  "Interactive  Sounding"); 
jPanell.add(jLabel3,  new  PaneConstraints("jLabel3",  "jLabel3", 
PaneConstraints.ROOT,  0.5f)); 

jPanell.add(jButton3,  new  PaneConstraints("jButton3",  "j'LabeB", 
PaneConstraints.BOTTOM,  0.8341232f)); 
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jPanell.add(jLabel4,  new  PaneConstraints("j'Label4",  "jButtonS", 
PaneConstraints .TOP,  0. 3579545 f)); 

} 

/**File  I  Exit  action  performed*/ 

public  void  jMenuFileExit_actionPerformed(ActionEvent  e)  { 

System.exit(O); 

} 

/**Help  I  About  action  performed*/ 

public  void  jMenuHelpAbout_actionPerformed(ActionEvent  e)  { 

Frame l  AboutBox  dig  =  new  Frame l_AboutBox(this); 

Dimension  dlgSize  =  dlg.getPreferredSize(); 

Dimension  frmSize  =  getSize(); 

Point  loc  =  getEocationO; 

dlg.setEocation((frmSize.width  -  dlgSize.width)  /  2  +  loc.x,  (frmSize.height  - 
dlgSize.height)  /  2  +  loc.y); 
dlg.setModal(true); 
dlg.showQ; 

} 

/**  Overridden  so  we  can  exit  when  window  is  closed*/ 
protected  void  processWindowEvent(WindowEvent  e)  { 
super  .processWindowEvent(e); 

if  (e.getIDO  ==  WindowEvent.WINDOW  CEOSING)  { 
jMenuFileExit_actionPerformed(null); 

} 

} 

/**  Action  to  perform  when  GDV  button  is  clicked*/ 
void  jButton3_mouseClicked(MouseEvent  e) 

{ 

try 

{ 

jButton3.setBackground(Color.green); 

makeGDVO; 

} 

catch  (Exception  ex) 

{ 

System.out.println("Caught "  +  ex.toStringO); 

} 

} 

/**Construct  a  Gridded  Data  Viewer  (GDV)  Application*/ 
void  makeGDVO 
{ 

try 

{ 
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makeGridViewer  topjf  =  new  makeGridViewer(); 

} 

catch  (Exception  ex) 

{ 

System.out.println("Caught "  +  ex.toStringO); 

} 

} 

/**  Action  to  perform  when  Image  Viewer  button  is  clicked*/ 
void  jButton2_mouseClicked(MouseEvent  e) 

{ 

try 

{ 

jButton2.setBackground(Color.green); 
makelmageV  iewer(); 

} 

catch  (Exception  ex) 

{ 

System.out.println("Caught "  +  ex.toStringO); 

} 

} 

/**  Construct  an  Image  Viewer  Applicatiom*/ 
void  makelmageViewerO 
{ 

try 

{ 

boolean  do3d  =  !((System.getProperty("ImageViewer.mode", 
"2D")).equalsIgnoreCase("2D")); 

ImageViewer  iv  =  new  ImageViewer("Satellite  Image  Viewer",  do3d); 
iv.  setV  isible(true); 

} 

catch  (Exception  ex) 

{ 

System.out.println("Caught "  +  ex.toStringO); 

} 

} 

/**  Action  to  perform  when  Sounding  button  is  clicked*/ 
void  jButton4_mouseClicked(MouseEvent  e) 

{ 

jButton4.setBackground(Color.green); 

makeSoundingO; 

} 
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/**Construct  a  Sounding  Application*/ 
void  makeSoundingO 
{ 

try 

{ 

new  InterSounding().show(); 

} 

catch  (VisADException  visex) 

{ 

System.out.println("Caught "  +  visex); 

} 

catch  (RemoteException  remex) 

{ 

System.out.println("Caught "  +  remex); 

} 

} 

} 
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C.2  Framel  AboutBox.java  Source  Code 


package  application!; 

import  j  ava.awt.  * ; 
import  j  ava.  awt.  event.  * ; 
import  j  avax . swing .  * ; 
import  j  avax  .swing. border .  * ; 


*  Title: 

*  Description: 

* 

* 

*  Created: 

*  Company: 

*  @author 

*  @version  1.0 

*/ 


IMetApps  Experimental  Application  -  Design  1 
This  is  an  experimental  application  using  design  1 .  This  experimental 
application  uses  Unidata  MetApps  prototype  stand-alone  apllications 
GDV.jar,  SoundingApplication.jar,  and  ImageViewer.jar. 

December  2001 
AFIT/ENP 

Captain  Harmen  P.  Visser 


public  class  Frame l_AboutBox  extends  JDialog  implements  ActionEistener  { 

JPanel  panel  1  =  new  JPanelQ; 

JPanel  panel2  =  new  JPanel(); 

JPanel  insetsPanell  =  new  JPanelQ; 

JPanel  insetsPanel2  =  new  JPanelQ; 

JPanel  InsetsPaneB  =  new  JPanelQ; 

JButton  button  1  =  new  JButtonQ; 

JEabel  ImageEabel  =  new  JEabelQ; 

JEabel  label  1  =  new  JEabelQ; 

JEabel  label2  =  new  JEabelQ; 

JEabel  labeB  =  new  JEabelQ; 

JEabel  label4  =  new  JEabelQ; 

BorderEayout  borderEayoutl  =  new  BorderEayoutQ; 

BorderEayout  borderEayout2  =  new  BorderEayoutQ; 

FlowEayout  flowEayoutl  =  new  FlowEayoutQ; 

GridEayout  gridLayoutl  =  new  GridLayoutQ; 

String  product  =  "IMetApps  Experimental  Application  -  Design  1"; 

String  version  =  "1.0"; 

String  copyright  =  "Copyright  (c)  2001"; 

String  comments  =  "This  is  an  experimental  application  using  design  1 .  This 
experimental  application  uses  Unidata  MetApps  prototype  stand-alone  apllications 
GDV.jar,  SoundingApplication.jar,  and  ImageViewer.jar."; 
public  Frame  l_AboutBox(Frame  parent)  { 
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super(parent); 

enableEvents(AWTEvent.WINDOW_EVENT_MASK); 
try  { 
jblnitO; 

} 

catch(Exception  e)  { 
e  .prints  tackX  rac  e() ; 

} 

pack(); 

} 

/** Component  initialization*/ 
private  void  jblnitQ  throws  Exeeption  { 

//imageEabel.setIoon(new  ImageIoon(Eramel_AboutBox.olass.getResouroe("[Your 
Image]"))); 

this.setlitleC'About"); 

setResizable(false); 

panel  1  .setEayout(borderEayout  1 ); 

panel2.setEayout(borderEayout2); 

insetsPanel  1  .setEayout(flowEayout  1 ); 

insetsPanel2  .setEayout(flowEayout  1 ); 

insetsPanel2.setBorder(BorderPaetory.ereateEmptyBorder(10,  10,  10,  10)); 

gridEayoutl  .setRows(4); 

gridEayoutl  .setColumns(l); 

labell  .setText(product); 

label2.setText(version); 

labels. setText(eopyright); 

label4 .  setT  ext(e  omments) ; 

insetsPanel3.setEayout(gridLayoutl); 

insetsPanel3.setBorder(BorderPaetory.ereateEmptyBorder(10,  60,  10,  10)); 

buttonl  .setText("Ok"); 

buttonl  .addActionListener(this); 

insetsPanel2.add(imageEabel,  null); 

panel2.add(insetsPanel2,  BorderEayout.WEST); 

this.getContentPane().add(panell ,  null); 

insetsPanel3.add(labell,  null); 

insetsPanel3.add(label2,  null); 

insetsPanel3.add(label3,  null); 

insetsPanel3.add(label4,  null); 

panel2.add(insetsPanel3,  BorderEayout.CENTER); 

insetsPanell.add(buttonl,  null); 

panel  1  .add(insetsPanell ,  BorderEayout.SOUTH); 

panel  1  .add(pane  12,  BorderEayout.NORTH); 

} 

/**  Overridden  so  we  ean  exit  when  window  is  elosed*/ 
proteeted  void  prooessWindowEvent(WindowEvent  e)  { 
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if  (e.getIDO  ==  WindowEvent.WINDOW  CLOSING)  { 
cancelO; 

} 

super  .processWindowEvent(e); 

} 

/**Close  the  dialog*/ 
void  oanoelQ  { 
disposeQ; 

} 

/**Close  the  dialog  on  a  button  event*/ 
public  void  actionPerformed(ActionEvent  e)  { 
if  (e.getSourceO  ==  button  1)  { 
cancelO; 

} 

} 

} 
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C.4  inters ounding. java  Source  Code 


package  application!; 

import  j  ava.awt.  * ; 

import  j  ava.  awt.  event.  * ; 

import  java.rmi.RemoteException; 

import  j  avax . swing .  * ; 

import  visad.VisADException; 

import  ucar.unidata.view.sounding.*; 


*  Title: 

*  Description: 

* 

*  Created: 

*  Company: 

*  @author 

*  @version  1.0 


inters  ounding  .j  ava 

This  class  is  used  to  build  an  Interactive  Sounding  window  from  within 
iMetApps 

Experimental  Application  -  Design  1 .  This  class  is  necessary  to  handle 
exceptions 

thrown  by  VisAD  and  the  precompiled  Sounding  Application  files. 

December  2001 

AEIT/ENP 

Captain  Harmen  P.  Visser 


public  class  InterSounding  extends  JErame 

{ 

public  Inters oundingO  throws  VisADException,  RemoteException 

{ 

super("Interactive  Sounding  Application"); 

/**This  listener  allows  sounding  to  be  closed  and  iMetApps  Control  Panel  to 
remain  open*/ 

addW indowEistener(new  W indow Adapter() 

{ 

public  void  windowClosing(WindowEvent  e){} 

}); 

new  SoundingApp(getRootPane(),  true); 

pack(); 

Dimension  screenSize  =  getToolkit().getScreenSize(); 

Dimension  frameSize  =  getSizeQ; 

setEocation((screenSize.width  -  frameSize.width)/2, (screenSize. height  - 
frameSize. height)/2); 

}; 
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C.5  makeGrid  Viewer  .java  Source  Code 


package  application!; 

import  j  ava.awt.  * ; 
import  j  ava.  awt.  event.  * ; 
import  java.util.*; 
import  j  avax . swing .  * ; 
import  javax. swing.  JComponent.*; 
import  ucar.unidata.ui.*; 
import  ucar.unidata.util.*; 
import  near. unidata,  gridviewer.  * ; 

*  Title:  makeGridViewer.java 

*  Description:  The  classes  contained  in  this  file  are  an  adaptation  of  the  Main.java, 

*  V  1.22  2001/05/01  15:21:07,  Copyright  1997-2000  Unidata  Program 

*  Center/University  Corporation  for  Atmospheric  Research,  P.O.  Box  3000, 

*  Boulder,  CO  80307,  support@unidata.ucar.edu.  It  is  part  of  the  MetApps 

*  library.  This  library  is  free  software  and  can  be  redistributed  and 

*  modified  under  the  terms  of  the  GNU  Lesser  General  Public  License  as 

*  published  by  the  Free  Software  Foundation;  either  version  2. 1  of  the 

*  License,  or  (at  your  option)  any  later  version. 

*  This  file  (containing  two  classes)  provides  a  way  to  create  a  Gridded 

*  Data  Viewer  (GDV)  Application  via  the  iMetApps  launchpad. 

*  Created:  December  2001 

*  Company:  AFIT/ENP 

*  @author  Captain  Harmen  P.  Visser 

*  @version  1.0 

V 

public  class  makeGridViewer  implements  TopLevel 

{ 

JFrame  top; 

Common  common; 

makeGridV  iewer() 

{ 

top  =  new  JFrame(" Gridded  Data  Viewer"); 
top.addWindowListener(new  Window Adapter()  {}); 
common  =  new  Common(top,  this,  false); 
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top.packO; 

top.setVisible(true); 

} 

public  RootPaneContainer  getRootPaneContainer() 

{ 

return  top; 

} 

public  boolean  IsAppletQ 

{ 

return  false; 

} 

publie  void  close() 

{ 

save(); 

System.exit(O); 

} 

public  void  save() 

{ 

common.saveConfigO; 

} 

} 

class  Common 

{ 

SerializedObjectStore  store  =  new  SerializedObjeetStore("metapps",  "GridViewer", 
"main"); 

private  Controller  control; 
private  UI  ui; 

private  Component  mainC; 

Common(Component  mainC,  TopLevel  topLevel,  boolean  isApplet) 

{ 

this.mamC=  mainC; 

uear.unidata.util.Debug.fetchPersistentData(  store); 

if  (Debug. isSet("util.showProperties")) 

{ 

try 

{ 

Properties  p  =  System.getProperties(); 
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Enumeration  enum  =  p.keys(); 

while  (enum.hasMoreElementsO) 

{ 

Object  key  =  enum.nextElement(); 

System.out.println("  "+key  +  "  =  "  +  p.get(key)); 

} 

} 

catch  (SecurityException  e) 

{ 

System.out.println("not  allowed  to  get  Properties"); 

} 

ucar.unidata.ui.Help.setTopDir("/auxdata/javahelp/GDV"); 

} 

control  =  new  Controller(topEevel,  store); 
ui  =  new  UI(  topEevel,  store,  control); 
control. setElI(  ui); 

control. addMapBean(  new  ucar.unidata.gis.worldmap.WorldMapBeanQ); 
control. addMapBean(  new 

near  .unidata.gis.shapefile.ShapeEileBean("/auxdata/maps/Countries. zip")); 
control. addMapBean(  new  ucar.unidata.gis.shapefile.ShapeEileBeanO); 

} 

void  saveConfigO 

{ 

control. storePersistentDataQ; 
ui.storePersistentDataO; 

store.put("MainWindowBounds",  mainC.getBounds()); 
ucar.unidata.util.Debug.storePersistentData(  store); 
store. save(); 

} 


} 
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